Re: [PATCH] prevent warnings from -shared-libgcc on mips-irix

[Olivier Hainque <hainque at adacore dot com>]

Richard Sandiford wrote:
> I think the idea is that if a process has some objects linked against
> libgcc.a and some objected linked against libgcc_s.so, the latter
> should always use the libgcc_s.so versions.  We don't want libgcc.a
> symbols in the executable preempting those in libgcc_s.so, for example.
> (It would make a bug-fix update to libgcc_s.so less effective.)

 Ooh, I see.

> Thus the definitions in libgcc.a must be hidden from users of libgcc_s.so.

 indeeeed, and the linker is expected to fetch the objects if there's no
 .so involved.

[...]
> I think we both agree that _enabling_ hidden visibility is the
> proper fix for this problem.

 Yes, more below ...

> It's just that no-one particularly wants to do all the work
> involved.

> Anyone who's come across the GNU ld assumptions in our build system
> has eventually decided that it's more pragmatic to keep the hidden
> support disabled.

 Humm, agreed.

 Another way to see it is to consider that what we'd like to be
 able to do with libgcc is common and that it's a strong requirement
 to enable any support at all. As you pointed out, libgcov does
 something similar eventhough there's no .so in sight.

 I still agree it would sound nice to be able to remain in between.

> The point of the comment was just to tell the next reader _why_ we
> don't simply enable .hidden support.

> Both of us had to find that out the hard way, and I just wanted to
> save the next person who hits this from doing the same.

 Sure, I agree it's a very good and important thing :-)

> ...how about making the comment longer?  Something like:
> 
>      /* Explicitly hide crt symbols that would normally be marked with
>         a "hidden" visibility attribute.
>  
>         We have traditionally disabled this attribute when using the
>         native linker because the native linker's visibility support is
>         not fully-compatible with the GNU linker's.  In particular, the
>         native linker does not pull in archive objects purely to resolve
>         references to the object's hidden symbols, whereas the GNU
>         linker does.
> 
>         The libgcc build system currently hides libgcc.a symbols
>         whenever visibility attributes are supported.  On targets
>         with GNU semantics, this makes sure that uses of libgcc_s.so
>         symbols in one dynamic object are not resolved to libgcc.a
>         symbols in another dynamic object.  But on targets with
>         IRIX semantics, hiding the symbols prevents libgcc.a from
>         working at all.
> 
>         It would probably be better to enable visiblity attributes for
>         IRIX ld and disable the versioning of libgcc.a.  It shouldn't
>         make anything worse, since libgcc.a symbols are global by default
>         anyway.  However, no-one has volunteered to do this yet.  */

 Looks really nice, thanks.  Minor things: 

 It would seem useful to generalize a bit, to make it explicit
 that libgcc is not the only "problematic" library, for instance

 << 
 The gcc build system currently hides symbols in some
 static libraries (typically libgcov.a or libgcc.a) whenever
 visibility attributes are supported.  On targets with GNU
 semantics, this makes sure that uses of libx.so symbols in one
 dynamic object are not resolved to libx.a symbols in another
 dynamic object.  But on targets with IRIX semantics, hiding the
 symbols prevents the static archive from working at all.
 
 It would probably be better to enable visiblity attributes for
 IRIX ld and disable the static archives versioning.  It shouldn't
 make anything worse, since libx.a symbols are global by default
 anyway.  However, no-one has volunteered to do this yet.
 >>

 Fine with you ?

 Besides, I think a more exposed hint in the "configure.ac" comments
 would be useful in addition, to hint early at the expectations for
 other targets or linker versions. For instance:

*** configure.ac        (revision 137871)
--- configure.ac        (working copy)
*************** gcc_GAS_CHECK_FEATURE([.nsubspa comdat],
*** 2077,2082 ****
--- 2077,2087 ----

  # .hidden needs to be supported in both the assembler and the linker,
  # because GNU LD versions before 2.12.1 have buggy support for STV_HIDDEN.
+ # In particular, we might hide symbols in static archives to prevent
+ # accidental resolution to them when a shared version ought to be chosen
+ # instead, and we rely on the linker still resolving from the static
+ # versions otherwise for such archives to remain functional alone.
+
  # This is irritatingly difficult to feature test for; we have to check the
  # date string after the version number.  If we've got an in-tree
  # ld, we don't know its patchlevel version, so we set the baseline at 2.13


 Thanks for your feedback,

 Olivier