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

[Alexandre Oliva <oliva@dcc.unicamp.br>]

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

>> 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

> We are talking ABI here. It covers data structures used in libc.

libc is just like any other library, except that the effects of
incompatible ABI changes are much more pervasive.  But the problem is
exactly the same for any other library's ABI change.

>> 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.

> The main problem is we can only have one libfoo.so/libfoo.a in one
> directory.

libfoo.so could always be a linker script, but that's not what I'm
talking about.  I'm suggesting to extend the linker to search more
than just libfoo.so when looking for a library.  It would also search
for lib$abi.foo.so, or even include sonames of dependent libraries in
this search.  It might get quite complex, but it's the only way to
ensure proper library versioning.

>> 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.

> I am not talking about any transitions. It is for new platforms with
> both 32bit and 64bit ABIs.

Then why were you talking about pre-existing libraries?

-- 
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