This is the mail archive of the
mailing list for the glibc project.
Re: linux-mips build fix
At 19:02 19.09.2002, Jakub Jelinek wrote:
On Thu, Sep 19, 2002 at 06:57:50PM +0200, Franz Sirl wrote:
Ah, so with STV_HIDDEN the situation which lead to the divdi3 mess can no
longer occur? Namely that the "LOCAL DEFAULT" libgcc symbols in a correctly
(linked against libgcc) built shared library would fulfill the need of
libgcc symbols of an incorrectly (not linked against libgcc) built shared
lib during runtime?
> At 18:08 19.09.2002, Ulrich Drepper wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >Franz Sirl wrote:
> >>Note that with Jakub's patch in now, for some platforms the symbol type
> >>changed from "LOCAL HIDDEN" (because they were pulled from libgcc) to
> >>"LOCAL DEFAULT", so they are visible for linking now.
> >Local is local, it's not available for linking.
> Sorry, one word is missing, I meant it's available for runtime linking,
> after all this was one of the reasons why HIDDEN was introduced after
No, it is not available for runtime linking either.
STV_HIDDEN was introduced, so that you can have variables and functions which
can be used by any of the objects which are linked into a shared library,
but it is not visible outside of the library.
Without that, you can have either static ones, which can be used only by
the object defining it, or global which are then visible outside
of the library (unless you use symbol versioning, that is).
How is this accomplished? Does ld -shared autoset STV_HIDDEN on a file? How
does readelf -a display STV_HIDDEN?