Re: Problems with symbols from libc_nonshared (fwd)

[Geoff Keating <geoffk@ozemail.com.au>]

> From: hjl@lucon.org (H.J. Lu)
> Date: Mon, 29 Mar 1999 08:16:07 -0800 (PST)
> Cc: schwab@issan.informatik.uni-dortmund.de, libc-hacker@cygnus.com
> 
> > 
> > On 29 Mar 1999 12:39:30 +0200, Andreas Schwab wrote:
> > >Zack Weinberg <zack@rabi.columbia.edu> writes:
> > >
> > >|> This is a bugreport forwarded from Debian.  I think we need to use a versio
> > >n
> > >|> map to force libc_nonshared.a symbols local when building shared libraries,
> > >|> sort of like what HJ did for libgcc.a in his egcs/Linux patches.
> > >
> > >That would violate the C standard.
> > 
> > Um?  I don't see how.  All it would do is prevent e.g. libreadline from
> 
> My guess is you can no longer override stat () in libreadline.
> 
> > accidentally exporting stat().
> > 
> 
> We may have to modify the linker not to include libc_nonshared.a for
> -shared.

Wouldn't it be better to add an extra feature to the linker: allow a
particular label in a .o file to be marked as "do not export", so that
"stat" and suchlike (particularly the libgcc.a stuff) are never
exported from a shared library unless they're actually provided by
user code (or the marking is overriden by versioning)?

This would solve all these problems in one integrated hit, and
requires no special hacks to gcc (well, you might want to add an
__attribute__ for the "do not export", if you liked).  It does mean
that old libraries should be recompiled, but you could work around
that by adding -lgcc -lc before those libraries on the linker command
line.

Otherwise, probably the thing to do is to require users to explicitly
specify the functions that each shared library is supposed to export.
Other OSs seem to end up doing this.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>