This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]