Chris G Demetriou wrote:
> > What do you need weak symbols in libc for?
> > I'll show you mine if you show me yours... 8-)
> 
> Shared libraries.
> 
> ELF shared libraries look like one big .o, in terms of the linking
> model...  I can't define it precisely (since i'm no an ELF guru), but
> it's more or less seomthing like:
> 
> If you've got 'real' (non-weak) symbols in your libraries that the
> user program also wants to define, lossage ensues.
> 
> One example of this is /usr/bin/pr: it defines a global FILE * named
> 'err'.  That gets confused with the libc (function) definition of
> 'err'.  SEGV.

So you need _every_ libc function that is in the programmer's name space
to have a name outside that space and a weak alias back to the original
name?

And the modified libc code has to work on ports where no weak alias
support exists and/or with a K & R compiler?!! (rhetorical 8-).

Does this mean you need a macro like HIDENAME() and code things like:

int
HIDENAME(sigpause)(mask)
    int mask;
{
    return (HIDENAME(sigsuspend)((sigset_t *)&mask));
}

[not sure that is a good example, but it was in a window nearby 8-)]

I was trialling this sort of thing to hide functions that libpthread
needs to supply a thread-specific version of.

Now I see a problem... if I had done such a thing to libc it would
suit both your ELF requirements and mine, but I would end up with the
ELF shared library problem occurring in libpthread. libpthread would
need non-weak symbols to override the weak ones in libc - then
libpthread wouldn't work shared under ELF. There are no degress of
"weakness". Hmmm. Any suggestions?

> chris
> 

-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au                          119 Cecil Street
Ph  +61  3 9690 6900                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137