Multilib and Linux.

[Roger Fujii]

rich-paul@rich-paul.net wrote:
>
> On Tue, 20 Apr 1999, Philip Blundell wrote:
>
> > the idea much.  I think the linker probably needs to be taught to modify its
> > search path based on the ABI in use.
>
> Here is an extremely ambitious approach:
>
> This is off the cuff, but what if we modified the .o format to allow more
> than one copy of the code to exist in a single file, with the linker trained
> to get the same version out of every file it links, or die if each and every
> file does not have a version some case.  For example:
>
> <See file skeletons below to understand this>
>
> Now if the linker is called, and asked to link the four files
> outlined below, and a foo32 executable requested, it would succeed.
>
> If a foo64 executable is requested, it would fail, since there
> is no foo64 section in afunc.o
>
> If a foo128 executable is request, it fails becaue there is no such section
> in the library.
>
> etc, etc.

Yup.  This idea was done in DomainOS by Apollo over a decade ago.  The
problems were:

really FAT binaries - and you still had to deal with data file issues
funky linking which most makefiles couldn't be coerced into doing
typed files (that's how apollo implemented it).

Neat idea, but in the end a real pain to deal with.

Personally, I like how solaris does it ( /lib, /lib/sparcv9) because it
allows one to do something like: (/lib/386, /lib/486, /lib/586, /lib/k6) for
optimized libraries for the processors.  PLUS don't forget that egcs doesn't
run *ONLY* under linux - it's already like that for the solaris, so it must
be somehow accomodated anyway (along with irix way).

Too bad we don't have named links like DomainOS has (it allowed you to say:

ln -s /lib/'$(TARGET)'/libc.a libc.a

- a really neat feature).

-r
 
--
Roger Fujii <rmf@lookhere.com>     Phone: (703)280-1243
Underemployed, and trying to keep it that way....