Garrett D'Amore wrote:
Has anyone given any thought to convincing OpenSolaris to use its own
proto area (populated by the install_h target or somesuch) instead of
assuming local system headers?
What about libraries? Startup code? Tools?
I have s story of a brute-force approach to a related
problem that might offer some insight.
For several years now I have maintained sparc and x86 build systems
that permit building of ON on a host that it not necessarily running
a closely-matched Solaris/ON release.
This started during Solaris 9 (on81) development. One sparc and one
x86 system could be used to build all releases from 2.6 thru 9/on81.
During Solaris 10 (on10) development the host was updated to
run on10 builds and was able to build 2.6 thru on10 up until
around build 31. At that stage a number of putbacks that
included kernel<->libc intimate kmowledge and some syscall
churn (I believe the two biggest hurdles we're the libc & libthread
merge and the fine-grained priv stuff) made it impossible to
build Solaris 9 and earlier and early versions of on10 on an
on10 system, and we split into 2 sparc and 2 x86 systems.
So now a single system builds Solaris 10 and Nevada and
another Solaris 9 and earlier, for each of sparc and x86.
We do this via chroot and automounter. To build in an
environment not matched to that of the host itself
you chroot into a "root image" that matches what you
do want to compile in. The root images are built by
ufsdumping an install of the environment you want
(that way all config like nis+, dns etc already works
for the environment you are in). The chroot works mostly
because it gets all the libraries in place not for
linking during compile but for dynamic linking of
the compiler bits as they run.
To make the chroot environment look like your native
environment we automount a tonne of stuff within it -
see the map entry below.
The systems have not required another split since that
mid-on10 split. However I can believe that some day
some major re-org of code could again make the Nevada
system unable to build on10 or early versions of
Nevada.
Below is the automount map entry for with on10
root image.
on10
/ -suid,ro tb2.uk:/tank/tools/rootimages/&/$CPU/latest
/devices -fstype=lofs,rw /devices
/dev -fstype=lofs,rw /dev
/share -fstype=lofs /share
/home -fstype=lofs /home
/vol -fstype=lofs /vol
/usr/dist -fstype=lofs /usr/dist
/var/tmp -fstype=lofs /var/tmp
/var/nis -fstype=lofs,ro /var/nis
/var/run -fstype=lofs /var/run
/var/adm/utmpx -fstype=lofs,ro /var/adm/utmpx
/var/spool/mqueue -fstype=lofs /var/spool/mqueue
/tmp -fstype=lofs /tmp
/export -fstype=lofs /export
/local -fstype=lofs,ro /local
/local/root -fstype=lofs,ro /
/etc/passwd -fstype=lofs,ro /etc/passwd
/etc/shadow -fstype=lofs,ro /etc/shadow
/ws -fstype=lofs /ws
/net -fstype=lofs /net
/usr/local -fstype=lofs /usr/local
/proc -fstype=proc,rw,suid,devices /&/proc
/dev/fd -fstype=fd,rw fd
/system/contract -fstype=ctfs ctfs
/system/object -fstype=objfs objfs
/opt/SUNWspro -fstype=lofs,ro /share/on10-tools/SUNWspro/SOS8
/opt/teamware -fstype=lofs,ro /share/on10-tools/teamware
/opt/onbld -fstype=lofs,ro /share/on10-tools/onbld
/etc/mnttab -fstype=lofs,ro /etc/mnttab
/var/spool/clientmqueue -fstype=lofs,rw /var/spool/clientmqueue
/share/SUNWspro_latest -fstype=lofs
/share/eu/lang/solaris/$CPU/links_perOS/latest_5.10/SUNWspro
/share/SUNWspro_prefcs -fstype=lofs
/share/eu/lang/solaris/$CPU/links_perOS/prefcs_5.10/SUNWspro
It's giant hack but that's the point - there's a lot of
stuff to defeat in achieving this.
Cheers
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
