This an alternative solution to the -Bsymbolic/-Blocal approach that I
exposed before. It doesn't require any loader/linker code modifications
but requires more work by the library maintainers and is better done
with upstream consensus (but this isn't strictly necessary).

First, we must define versioned symbols for the conflicting libraries.
This must be done by creating version scripts with only one version tag
(otherwise unversioned objects will not be able to bind to versioned
symbols).
Here is an example: (note: this might not be completely correct for
libpng)
libpng2.ver:
LIBPNG_2.0 {global: png_*; local: *;};

libpng3.ver:
LIBPNG_3.0 {global: png_*; local: *;};

Then, a --version-script argument should be added to LDFLAGS and the
affected libraries and all the libraries that use them should be
rebuilt.

After we do this, however, we have a problem: programs linking to the
libraries will be built with versioned symbols.

This reduces binary compatibility since having objects with different
versions schemes will cause failure and having versioned objects using
unversioned ones will cause warning messages.

This can be easily fixed by creating a /usr/lib/dev directory and
modifying the GNU binutils package so that it is in front of the linker
search path.
Then, conflicting libraries can be built in a normal versioned version
and in an unversioned one that is installed in /usr/lib/dev and put in
the -dev package for the library.

Not building programs with versioned symbols works because the library
they use is always the first one in the search path. However, if the
program is unversioned and more than one of the conflicting libraries is
used, all libraries that are or use one of the conflicting libraries
which is not the one used by the main program must be compiled with
-fPIC (otherwise the library symbols will be resolved by the undefined
symbols in the main program resulting in the wrong library version being
used). This should already be the case for all libraries so this
shouldn't be a problem.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to