[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC 3.2 transition



On Friday 16 August 2002 21:47, Martin v. Loewis wrote:
> Steve Langasek <vorlon@netexpress.net> writes:
> > How would this work?  Would those using gcc-2.95 software have to set an
> > rpath or $LD_LIBRARY_PATH to take advantage of the compat libs?  If so,
> > it hardly seems worth the effort; manual intervention is still required
> > to make legacy binaries work.
>
> Not necessarily: you can write wrapper scripts around the executable
> which automatically set LD_LIBRARY_PATH, then invoke the original
> binary. That has worked very well in the past.
>
While this hack would make it unnecessary, I consider it a lack in the 
linker. In my eyes, the program should ask the linker at startup to provide a 
specified set functions. For since C++ has bigger requirements that stem from 
function overloading and other stuff, the specification consists of the API 
(which is -oversimplified- the version of the header files) and the ABI 
(which must match the compiler the app was compiled with). 

I'm not totally aware of the way the dynamic linker works or how an ELF 
executable is structured, but I believe it would be possible to add a field 
in ELFs header that says which ABI to use and get the linker to parse it.

Still, I have one question left: will C++ be the only language that profits 
from this, are there other languages that have different ABI by different 
compilers ? And would such a function be used again even for C++ ? (hint: 
multi-vendor ABI standard)

At last a crazy idea: what happens if I link object files from two different 
compilers into one lib? I mean I compile foo.cpp once with compiler A and 
then again with compier B and create a lib from both of them. The only 
drawback I see at the moment is that the resulting lib would be approximately 
be twice the size and, even worse, global objects would be instantiated 
twice, bad if they acquire and lock some kind of resource .....

cheers 
Uli

PS: is there any way to get the BTS to spew out a list of all bugs of 
packages that don't build with a more standard-conformant compiler (GCC3) ?




Reply to: