This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: More on 32bit/64bit ABIs under Linux


On Apr 22, 1999, hjl@lucon.org (H.J. Lu) wrote:

>> Then the super-user could play tricks on me by creating
>> /ABI32/home/oliva/lib :-)

> He/she can also do

> # rm -rf /home/oliva

But that wouldn't be as much fun :-)

>> Why can't it be taught to hande multiple ABIs too?  I like you idea of
>> introducing the ABI in the SONAME of the library; why couldn't it also
>> use it when searching for a library?  So that, when you specify
>> -mabi=64 (default) -lfoo, it will look for libfoo-64.so, or maybe

> -mabi=64  may not be enough. As I mentioned on my soname proposal, you
> need to keep track the interface of libfoo, the interface of libc used
> to compile libfoo and 32bit vs. 64bit.

The interface of libc is just a special case of a much more general
problem you're overlooking.  It's not only libc that can change: any
other library your library depends upon may have an incompatible
change, and then you'd need some way to encode it in the soname of the
dependent library.  That's where the linker can play a role that the
dynamic linker is already playing: it could analyze library
dependencies and pick up the right version of a library, so that the
dependencies can be properly satisfied.

>> lib64.foo.so, if you will, which is less likely to lead to conflicts.
>> Then we wouldn't need special directories at all: the linker would
>> search for the library with the appropriate ABI prefix.  If it can't
>> find it, it would fallback to the traditional library naming scheme,
>> making sure that the library actually complies to the selected ABI.

> The problem is it is a big change. The existing libraries won't work
> and the linker people may not like it.

They would; that's why I'm suggesting the fallback to the traditional
naming scheme.

> It can be very complicated.  Symlink to libfoo.so/libfoo.a seems to
> be a simple solution.

I don't think it's a good solution.  We could end up having as much
trouble as we had in the transition to libc6.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]