glibc hackers?

(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 get going, 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
helping to add 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 because 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 that links in the same library more than once 
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.....

I've found one guy who's willing to help, but he can't do it all himself.
So, assuming people agree this is a wise course of action to take, we'll
need at least one more person.

If we can't find anybody within a reasonable timeframe
(say the next month or two) then I'll sit down and bring myself up to speed
on all the skills necessary. The reasons I'm not keen on doing it myself are:

* My C hacking skills are mediocre at best (but getting better as I hack on Wine)
* Don't want autopackage to lose momentum
* Already have too much to do, yet another project is the last thing I should take on right now :)

Anybody up for it, or know somebody who might be?

thanks -mike