develooper Front page | perl.dist | Postings from May 2002

Integrating perl into Solaris.

From:
Alan Burlison
Date:
May 14, 2002 06:56
Subject:
Integrating perl into Solaris.
Message ID:
3CE11738.7EC069FA@sun.com
Firstly, a tiny bit of background on how Solaris is built; we have a
central source code repository held on a 'Gate' machine.  This machine
builds the OS and all commands/libs every night (other bits, e.g. X11,
have separate gates).  The Gate machine runs the version of Solaris that
was built last night (including perl).  We use perl during the build
itself, and cross-version building is allowed, e.g. building Solaris 10 on
Solaris 9.  Anyone can build a copy of the OS by taking a copy of the Gate
and building that.

As with any cross-compilation, as the OS is built the headers and
libraries are constructed into a new OS image ('proto') area.  All headers
and libraries need to come from here, rather than from the platform that
we happen to be building on. 


Here are some of the constraints and problems I came across, same major,
some minor:

1.  Other freeware packages that we ship (e.g. gimp) live in a separate
gate, and can therefore use Configure and/or whatever build mechanism they
normally use.  Perl however can't, as it lives within the Solaris source
base, and must build as part of Solaris.

2.  We can't run configure every time Solaris was built, as every
different machine would produce a different one each time, and
cross-compiles from one OS version to another would also give incorrect
results.

3.  We can't use the standard perl Makefile as it won't integrate into the
Solaris build environment - for example, it doesn't have the targets used
by the standard Solaris build, it doesn't use the correct compiler flags.

4. When building Solaris is it vital to use headers from the proto area,
rather than the ones on the platform.  Neither the standard perl Makefile
nor MakeMaker know how to do this.

5. MakeMaker doesn't propagate it's arguments correctly to lower-level
modules.

6.  MakeMaker insists in setting LD_RUN_PATH (unnecessarily!), and this
screws up the resulting objects big-time if they are not built for and
installed into the same location.

7. Make command-dependency checking as used in the Solaris build blows up
spectacularly when used with MakeMaker-generated makefiles.

8. When we build Solaris, the 'install' target doesn't install into the
final location as would a normal perl build, it installs into an image of
the OS in the current build workspace.  installperl doesn't know how to do
this.

9 .packlist contents end up being wrong if you build for one location and
install into another.

10.  installperl moans if you don't run 'make test'.

11. installperl moans about other versions of perl in your path

12. installperl uses 755 on executables rather than 555 - I have no idea
why.  It also doesn't ensure that the umask is sane before doing stuff -
we use 022.

13.  If you have the source checked into SCCS (your sympathy is
appreciated ;-), installperl kindly installs the SCCS directories and all
their contents for you as well.


Here are the steps involved in integrating the perl source into Solaris:

1. Start with a vanilla perl source tree, and a vanilla Solaris source
tree.

2. Run Configure on whatever architectures we are going to build, with a
hacked up config.over, a whole slew of command-line overrides and then
munge the config.sh some more with sed.  Check the resulting config.sh
into the Solaris source tree.

3. Identify just the files we need.  We don't allow 'dead code' in the
Solaris source base, so all the stuff we don't need (e.g. VMS, Win32
files) need to be removed.

4. Check what is left into the Solaris source tree.

5.  Add in a modified version of installperl that has fixes for the
problems listed above.

6.  Add in a modified version of MakeMaker.pm into a build-time-only
location, and point to it by setting PERL5LIB.  This pulls in a new MM_XXX
file (ExtUtils::MM_Solaris) which fixes the MakeMaker issues listed
above.  Doing it this way avoids having to hack MY:: methods into every
single module Makefile, allows us to override bits of MakeMaker not
accessible via the MY:: override mechanism.  With this in place, we can
use the standard 'miniperl Makefile.PL; make' incantation (more or less)
to build all the modules.

7.  Top it all off with half a dozen handwritten Makefiles, and a couple
of machine-generated ones.

8.  Beat repeatedly on the whole mess until it all works.

Alan Burlison



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About