This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: More on 32bit/64bit ABIs under Linux
- To: oliva@dcc.unicamp.br (Alexandre Oliva)
- Subject: Re: More on 32bit/64bit ABIs under Linux
- From: hjl@lucon.org (H.J. Lu)
- Date: Thu, 22 Apr 1999 13:37:00 -0700 (PDT)
- Cc: libc-hacker@cygnus.com, egcs@egcs.cygnus.com
>
> > if libfoo changes its ABI, ${libfoo_version} should be changed.
>
> But who about libbar that depends on libfoo? The same version of
> libbar might be built linked against different ABIs of libfoo.
> Shouldn't its soname include the soname of the particular libfoo it
> depends upon? Why should libc be a special case? Isn't binary
> compatility as important for other libraries as it is for libc?
libc doesn't have to be in soname. You can change ${libfoo_version}
with
libfoo-${ABI}.so.${libfoo_version}
The reason I suggested ${libc_version} is it tells me which C
library is compiled against. In many cases, this information
is very useful. It is just my opinion.
> > As I said, it is too complex to me. /ABI32 is easier to implement.
>
> But it's more error prone. I, for one, wouldn't like to install a new
> version of a library with ABI32 in /usr/local/lib, link with
> -L/usr/local/lib and see the linker use the old version just because
> it tried to outsmart me by searching /ABI32/usr/local/lib instead.
>
There is no perfect solution. You can write down your proposed linker
change in some detail. Let's discuss it with linker users as well as
linker writers.
--
H.J. Lu (hjl@gnu.org)