This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
> At 18:08 19.09.2002, Ulrich Drepper wrote:
> >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 all, or?

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).
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?
How is this accomplished? Does ld -shared autoset STV_HIDDEN on a file? How does readelf -a display STV_HIDDEN?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]