This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Possible ld.so modifications
Mike Hearn <mike@theoretic.com> writes:
> > 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
Yes, you are.
> 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.
Sure, but how many applications does this apply to? If SDL was
changed at some future point to accept/extract PNG structs then your
hacks would silently break, because you would be using SDL compiled against
version 2 and using version 3.
There are also a whole pile of libraries that silently store
information behind the APIs, gtk being the obvious example.
> > 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
Why? After you've setup a build system, it's a relatively simple
matter ... compared with ad-hoc hacking of symbol versioning into
libraries, which is very fragile when it does work and impossible in
some cases.
> 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 fork a version with symbol versioning, if you do it well then I
see no reason that distributions won't be happy to use your version
instead.
> 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.
This is only a problem if you need to have the same .so major and
minor on all platforms, which doesn't seem useful to me.
> 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.
See above for why this is a massive amount of work, every time you
recompile an application, assuming you aren't trying to distribute
random untested binaries.
--
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null