This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] prevent warnings from -shared-libgcc on mips-irix
Olivier Hainque <hainque@adacore.com> writes:
> 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 ?
Yeah, looks good, thanks.
> 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
Looks OK to me, but it needs approval from a build-system maintainer.
Richard