glibc hackers?
Mike Hearn <[email protected]>
| Newsgroups | gmane.linux.lsb.discuss |
|---|---|
| Message-ID | <[email protected]> |
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