🚀 go-pugleaf

Do you build gcc and then then install it in such a way that many machines
mount the gcc-lib tree?  In particular, do you build gcc on a Sun machine
such as a SPARCstation and then have all sorts of Suns mount it, with
possibly different kernel architectures (sun4, sun4c, sun4m) all mounting and
using it?  Then read on.

Interesting problem came up while I was building top 3.1, and trying to decide
on the multiple kernel arch support mechanism.  One of the groups I work for at
JPL has mostly all sun4, sun4c and sun4m (along with an SGI and a NeXT; I'm not
worried about those yet) Suns.

I decided to be brave and compile "top" with gcc 2.4.5; these folks have gcc
installed in a (Sun-) globally mounted /usr/local heirarchy (i.e., the lib
stuff is under /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.4.5/... and
/usr/local is automounted to all Suns).

Well, it turns out that when the gcc install runs "fixincludes", it creates a
"/usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.4.5/include/machine" symbolic
link.  Normally, "/usr/include/machine" is a link to "../kvm/machine", which
of course makes it kernel architecture-dependant:

isolar:1:47 [/] % ls -l /usr/include/machine
lrwxrwxrwx  1 root      14 Jan 24  1993 /usr/include/machine -> ../kvm/machine
isolar:1:48 [/] % ls -l /usr/kvm/machine
lrwxrwxrwx  1 root      16 Jan 24  1993 /usr/kvm/machine -> ../include/sun4c

But gcc takes /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.3/2.4.5/include/machine
and resolves it completely; i.e.

isolar:1:50 [/] % ls -l /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.4.5/include/machine
lrwxrwxrwx  1 root            7 Jul  7 12:35 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.4.5/include/machine -> ./sun4c

In other words, you now have a machine-dependant symlink inside a tree which
is (supposed to be) mountable across machines of the same (user) arch.

It turned out that compiling top's "machine.c" eventually included a file
which was specified as "#include <machine/something.h>", so it ended up
pulling the sun4m versions of these files from the "fixincluded" directories
into the .o (i.e., gcc was built on a sun4m there), and the resulting
executable (I was compiling "top" on a sun4 kernel arch) didn't work.

You can "fix" this by removing the .../gcc-lib/.../machine symlink, but that
causes gcc to pick up the normal /usr/include/machine files; thus losing the
fixinclude'd changes.  This is mostly benign (you'll get lots of complaints
about extraneous text after "#endif"'s), but in some cases the changes are
things like

	#if defined(sun4c) || defined(sun4m)

which "fixincludes" changes to

	#if defined(__sun4c__) || defined(__sun4m__)

so architecture-dependant code which needs to know what kernel arch may fail
in strange and mysterious ways if you remove this symlink ...

Anyone else run across this conundrum before?

-- 
	- Greg Earle
	  Phone: (818) 353-8695		FAX: (818) 353-1877 [Out of order now]
	  Internet: earle@isolar.Tujunga.CA.US
	  UUCP: isolar!earle@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle