Our docs about --enable/--disable-visibility

Jonathan Wakely jwakely.gcc@gmail.com
Sat Oct 29 12:26:00 GMT 2011


On 29 October 2011 10:42, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> in order to **enable** an effective use of -fvisibility=hidden together with
> namespace std instantiations. And indeed, just passing --disable-visibility
> allowed him to elegantly solve his problems. Thus, what the heck is going on
> in the docs? Do we have it somehow **backward** in the docs? Or, more
> likely, we should tweak the text and at the end say something along the
> lines ".. so that -fvisibility works for user code without affecting the
> external-visibility mandated by the Standard for the namespace std
> entities"? Some sort of "protection" so to speak? English to be improved...

Yes, that's my interpretation: users can use -fvisibility=hidden
without getting segfaults because they've hidden parts of libstdc++
that must not be hidden.

Vincenzo's use is not the typical one, he specifically wants to hide
libstdc++ entities, so for his case the docs do seem misleading.  But
for what I believe to be the more common use of -fvisibility=hidden
the docs are correct, but could be clarified as you suggest.


In 4.2 and later, enables or disables visibility attributes. If
enabled (as by default), and the compiler seems capable of passing the
simple sanity checks thrown at it, adjusts items in namespace std,
namespace std::tr1, and namespace __gnu_cxx <INS>to have default
visibility</INS> so that -fvisibility options <DEL>work</DEL><INS>can
be used without affecting the external-visibility mandated by the
Standard for the namespace std
entities</INS>

I'm not really sure about "mandated" because the standard is silent on
the subject of shared libraries, although hiding std entities could
cause ODR violations.

> Minor detail: I see that --enable/disibility-visibility may give the wrong
> impression, as something passed at *global* configure time, that it switches
> on/off the entire visibility mechanism at the compiler level too, maybe
> something like --enable-libstdcxx-visibility or
> --enable-libstdcxx-namespaces-visibility?!? But this is a detail at this
> stage.

Agreed.  I've wondered sometimes whether all libstdc++-specific
configure options should start with --enable-libstdcxx-



More information about the Libstdc++ mailing list