This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Our docs about --enable/--disable-visibility


On 29 Oct, 2011, at 2:26 PM, Jonathan Wakely wrote:

> 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.
> 
Can somebody provide me an example of a code that segfaults if "namespace std" is not default visible?
I never had problems, neither with std nor with other libraries such as boost.

> 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.
> 
Our problem is actually with the too many visible symbols generated by std (and other templated libraries more in general).
For what std is concerned there are many symbols that belong to the details of the implementation (for instance all the components of std::sort)
that in my opinion are very good candidate to stay hidden.
There is also the issue of declaring or not those functions "inline". Since 4.6 the gcc heuristic for inlining had become much more powerful and flexible:
in my opinion all std functions could be declared "inline" and then let the compiler decide what to do. This would also partially solve the visibility problem
as -fvisibility-inlines-hidden would could kick in.


vincenzo




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