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 12:06:12 -0700 (PDT)
- Cc: libc-hacker@cygnus.com, egcs@egcs.cygnus.com
> >> 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
We are talking ABI here. It covers data structures used in libc.
> 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.
>
> >> 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.
>
As I said, it makes the linker too complicated. We tried similar things
before. It didn't work too well. We went to back libfoo.so/libfoo.a.
> > 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.
>
I am not talking about any transitions. It is for new platforms with
both 32bit and 64bit ABIs.
--
H.J. Lu (hjl@gnu.org)