[lsb-discuss] glibc hackers?

Mike Hearn mike at theoretic.com
Sat Feb 22 06:56:04 PST 2003


(this is a resend, the previous one didn't appear to get through. btw,
it's not obvious where to find mailing list archives on the new site)

Hi,

I was going to wait for the packaging group to be set up, but I realised
there wasn't any real reason to wait.

A few weeks ago it was mentioned that some people on this list had
experience of glibc hacking... I'm trying to find somebody who fancies
adding support for -Bgroup and possibly -Bdirect semantics to ld.so

Roland McGrath says they are interesting in having such features here:

http://sources.redhat.com/ml/libc-alpha/2003-02/msg00105.html

but warns the work is not to be underestimated. A quick recap of why
this is a very useful/necessary thing to have:

ELF by default uses global symbol scope. That means if you have multiple
versions of the same symbol (ie multiple versions of the same library)
linked in to a process, it will die.

This causes problems for building portable dynamically linked binaries.
If you link your Tetris-killer against libpng.so.3 and libSDL_image, if
the distro was compiled with libpng.so.2 you'll end up with both major
version 2 and 3 linked in, you have no control over which version SDL
links in, and the app will die. Needless to say, that means that if you
distribute a binary you can't guarantee it won't instantly segfault for
no apparent reason, which kind of kills portable packaging dead. Oops.

There are a couple of solutions to this:
   - Make everything use symbol versioning. Unfortunately symvers are
not always appropriate, I've touched on their disadvantages in other
threads so I won't do so again here.
   - Implement group symbol scope like on Solaris. The link editor (ld)
supports this flag now, but the rtld (ld.so) ignores it.

Group symbol scoping allows you to link a library with -Bgroup (or
toggle the bit flag i think if you don't want/cant recompile the
library), and then symbols will be resolved in the current "group".
Exactly what is in the group can vary, the Sun docs on the feature are
available here:

http://docs.sun.com/db/doc/816-1386/6m7qcobku?a=view#chapter3-13

So basically, I personally consider this to be a pretty critical issue
that needs to be solved if we're going to move beyond "all LSB binaries
must supply every dependancy not in the spec". 

Is there anybody here with the necessary skills, or who knows where I
could find somebody with those skills? Obviously those people would need
a bit of time or some sponsorship or something also.....

thanks -mike





More information about the lsb-discuss mailing list