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

[hjl@lucon.org (H.J. Lu)]

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

libc is used by all other libraries and executables. When the other
library changes its ABI, it should change its version. That is why
suggested

libfoo-${libc_version}-${ABI}.so.${libfoo_version}

if libfoo changes its ABI, ${libfoo_version} should be changed.

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

lib$abi.foo.so may not a bad idea. As I said, it is too complex to me.
/ABI32 is easier to implement.


-- 
H.J. Lu (hjl@gnu.org)