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


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


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