This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: Soname for 32bit/64bit Linux
- To: jj@sunsite.ms.mff.cuni.cz (Jakub Jelinek)
- Subject: Re: Soname for 32bit/64bit Linux
- From: hjl@lucon.org (H.J. Lu)
- Date: Thu, 22 Apr 1999 12:00:31 -0700 (PDT)
- Cc: egcs@egcs.cygnus.com, libc-hacker@cygnus.com
>
> > There is nothing really preventing us from putting a library, libfoo,
> > with different ABIs in a directory, say /usr/lib. The only problem
> > is the linker will search for libfoo.so and libfoo.a when -lfoo is
> > passed. It may not find the right one.
> >
> > To resolve it, we require
> >
> > 1. soname of a shared object for libfoo, should not be libfoo.so. The
> > real filename of a shared object for libfoo, should not be libfoo.so
> > either.
>
> Why is this needed? At least 32 and 64bit ABI are easily detectable by both
> linker and run-time linker and ldconfig, so I wonder why should we bloat
You can only have one libfoo.so/libfoo.a in one directory.
> our executables (because it will appear in their DT_NEEDEDs) and libraries.
How much will executables and libraries bloated?
> The only exception I see here is the soname of the dynamic linker itself, as
> it is the kernel who looks that up and it does not go through any search
> paths, so dynamic linker's soname has to be different, that's all IMHO.
>
> >
> > 2. soname of a shared object for libfoo should encode ABI, which
> > is calling convention plus the data structure for libfoo and
> > data structure for libc used to compile libfoo. We can use
> >
> > libfoo-${libc_version}-${ABI}.so.${libfoo_version}
>
> This one is really needed if you want to keep libraries of different ABIs in
> one directory. The question is whether you want that...
>
You can install the existing 32bit binary packages on the
64bit machine. At the same time, you can make the 64bit ABI
native and default.
--
H.J. Lu (hjl@gnu.org)