On Fri, Mar 07, 2003 at 12:50:25PM -0500, Stephen Frost wrote:
> Hey all,
>
> Please excuse the (minor) cross-post but I think the technical
> committee needs to find an answer and that answer then be set in
> policy.
>
> We need to make a decision on how to properly handle multiple library
> versions ending up linked into the same process. A few of the options
> that I've heard, though they may not be the best, are:
>
> - Implement versioned symbols
> - May cause binary compatibility issues
> - Doesn't follow LSB (I believe..)
> - Could be difficult to do correctly
>
> - Conflict between library versions
> - Wouldn't allow valid setups where the versions aren't linked into
> the same process
> - Lots of packages would end up uninstallable for certain library
> upgrades
>
> - Don't implement versioned symbols
> - Continue to have problems with multiple libraries being linked in
> - No compatibility issues
>
> At the moment some people have versioned their libraries in order to
> fix the issue, potentially breaking compatibility and LSB. Other
> people don't have versioned symbols which brings up the problems like
> OpenSSL 0.9.6 and 0.9.7 being linked into the same process and
> crashing ssh when using libnss-ldap or libpam-ldap.
>
> At the moment I tend to think versioning the symbols is the 'right'
> thing to do and we should push to get upstream, other distros and LSB
> to do that too. I don't think leaving things the way they are is
> acceptable.
>
> Stephen
Dear all.
I strongly believe that these are both wrong solutions. As a much
better alternative, I suggest the following method, which has
been an integrated and successful part of many other operating
systems for at least 15 years.
Modify libdl.so.2 to change it symbol lookup engine as follows:
Old algorithm:
When ELF file libxyz.so or /bin/xyz requests the address of
symbol zzz, and multiple .so files in the address space provide
a symbol named zzz, haphazardly choose the first one
encountered, even if unrelated.
New algorithm:
When ELF file libxyz.so or /bin/xyz requests the address of
symbol zzz, and multiple .so files in the address space provide
a symbol named zzz, use the following priority list to choose
the proper one:
1. LD_PRELOAD-ed libs whose header references the specific
.so file which would be chosen by skipping to 3.
2. Any other LD_PRELOAD-ed lib
3. libs explicitly referenced by the header of the requesting
binary xyz.
4. Any remaining libs (this should spew a warning).
With this intelligent but simple priority list, the effect would
be:
if /bin/foo references libdb.so.3 and libbar.so.1 and
libbar.so.1 references libdb.so.4, then the the references to db
functions in foo refer to libdb.so.3 and those in libbar.so.1
refer to libdb.so.4, yet neither foo, libbar, libdb.so.3 nor
libdb.so.4 have been modified (or even relinked) to make this
work.
On that other commonly used OS, this routinely allows the mixing
of same named functions in one address space. It is quite
common (on that OS) for a single address space to contain
multiple (different) versions of libc (e.g. gcc-3.2 and
gcc-2.95). It is quite common (on that OS) for a subsidiary
library (such as libnss_resolv) to export functions such as
gethostbyname, with the full expectation and assurance that
callers referencing libc.so.6 will still get the gethostbyname
implementation in libc.so.6 (which internally calls the
gethostbyname in libnss_resolv if so chosen by nss
configuration).
Phrased in a completely different way, the idea is that
libdl.so.* should treat each .so file as representing a separate
namespace and resolve symbols according to the namespace
specified by the caller (with a special exception for LD_PRELOAD
and possibly libpthreads.so). As a future extension, a calling
binary may explicitly import individual symbols from specific
.so files. This would e.g. make it easier for a program to use
libbind and glibc together.
Hope this solution helps
Jakob
P.S.
I actually looked at the libdl source in glibc, but I did not
grok the implementation details well enough to write a patch.
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
