Re: Multilib and Linux.

[rich-paul@rich-paul.net]

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.

Now if you REALLY want to get funky, you can extend this idea to have the
debugging and profiling versions of functions live in this file as well.
The .o file is really an archive, with a section for each type.  There
could be rules, such as if a foo32-debug build is requested, and there
is a foo32 section in one executable but no foo32-debug section, those
are compatable and the link continues, with no debugging information in
that object.  But if there are no compatable sections, the link fails.

The foo32-debug idea would by extension work for a foo32-debug-pic and a
foo32-pic section, for building shared libraries.

And you you REALLY REALLY want to get  funky, hack the compiler so that if
it's invoked as follows
	gcc -c -zzz=foo32,foo64,foo128,foo32,foo32-pic -o doit.o
it will read and parse the files one time, and produce the doit.o file
produced thereafter.  Of course this could complicate the compile process,
since it would require that differant pre-processor conditions exist at
the same time, but 99.999% of the code should generally be the same.

Perhaps a better approach would be for the compiler to dump a rich parse tree,
with the invarients processed and the varients stubbed to a file, say
doit.o.c.preparsed, and then invoke the back end four times on this file.
Actually, I think that that's the best way to implement it.

Also, I would probably set libraries up so that they could be EITHER:
	an archive of archives of old style .o files, so that you could seek,
	read and process the section you're interested in.
		-- or --
	an archive of new multios, which would be put into the only section
	in the library -- which would be called default or multi, a reserved 
	section name
		-- or --
	an archive of the first type, with several sections for foo32: and
	foo64:, etc, PLUS a section called multi, containing unsplit objs.

	The archiver would be responsible for deciding what kind of archive
	to build.

On a similar principal, if asked to search /usr/lib, the linker could
first search /usr/lib/foo32, for files that were assumed to contain only
a foo32 section.


There are performance issues with shared libraries which I haven't con-
sidered, but this is a thought.

doit.o:
	foo32:
		variable int x
		function doit
	foo64:
		variable int x
		function doit
	foo128:
		variable int x
		function doit
	foo256:
		variable int x
		function doit
	foo32-pic: #This is for linking into a shared library.
afunc.o:
	foo32:
		function afunc
	foo128:
		function afunc
	foo256:
		function afunc
		
anotherfunc.o:
	foo32:
		function anotherfunc
	foo64:
		function anotherfunc
	foo128:
		function anotherfunc
	
alib.a
	alibfunc.o:
		foo32:
			function alibfunc
		foo64;
			function alibfunc
---
There is a party that  |  Libertarian Party  |  A victimless crime is
supports the right to  |  http://www.lp.org  |     a contradiction in 
free speech and        |    The Party of     |                 terms.
encryption!!           |      Principle      |