Re: Possible ld.so modifications

[Mike Hearn <mike at theoretic dot com>]

>  It doesn't matter what he does, you can't compile an application
> against one version of a library and then magically expect it to run
> against a different version automatically (if the maintainer
> guarantees a stable ABI between those versions, that's different).

I understand that, and this *isn't* what I'm trying to do. Our problem
is that if a program implicitly links in 2 different versions of the
same lib, the symbols will conflict because the linker doesn't check the
symbols in the libraries it's linked against first.

ie:

Frozen Bubble Game (frozen-bubble.org)
   - Linked against libpng3
   - Linked against libSDL
       - Distro compiled libSDL against libpng2

Frozen Bubble doesn't use libpng2, and doesn't care about it, but
because when symbol fixup occurs the symbols from libpng2 imported via
libSDL conflict with the symbols from libpng3 (which it's actually
linked against), badness occurs.

>  Autopackage needs to recompile applications for the environment they
> are going to run in, in the general case.

It's impractical to compile every app for every version of every distro,
which is what this problem implies. In the long term symbol versioning
is useful for some of the most widely used libraries, but having spoken
with library maintainers I've been told it's not always practical, nor
something they'd accept patches for. 

So we need to attack the problem from two angles. The first is to make
it easier and more practical for people to use symbol versioning in
their libs (and to raise awareness of it). However, there are some
issues with symvers that I just don't know the answer to - for instance,
the lack of portability it implies (it's a gnu system only) and many
libs are designed to be portable between forms of unix and even windows.
That's one of several points that were raised.

The other angle is to apply the patches from Luca Barbieri, allowing us
to compile apps with -Blocal. This patch is minimally invasive and puts
libraries the binary is actually linked against first in the symbol
lookup order, and then it continues as normal.

As the compile stage won't work unless you explicitly link against every
lib you need, this can't break apps because no apps can rely on 
implicit linking, so users and developers shouldn't ever notice any
difference (except their apps don't randomly segfault).

As far as I can tell though, Lucas patch was never applied, and no
particular reasons were given. I did ask what was wrong with them, but
got no reply, and as I leave for home on Monday I was going to leave the
issue be until the new year, when I'd be able to answer email again.

As this is something that affects all libs (though some more than
others) and I've been given credible arguments against symbol versioning
in some cases I'm not convinced it's a case of "we shouldn't work around
broken libs" - I think both sides need to do something.

thanks -mike

-- 
Mike Hearn <mike@theoretic.com>