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

[Vincenzo Innocente]

On 3 Nov, 2011, at 12:34 PM, Jonathan Wakely wrote:

> On 2 November 2011 14:50, Vincenzo Innocente wrote:
>> 
>> On 1 Nov, 2011, at 8:09 PM, Jason Merrill wrote:
>> 
>>> On 10/31/2011 06:41 AM, Vincenzo Innocente wrote:
>>>> The problem is that "default" means "force external visibility", not "use user visibility".
>>> 
>>> The default for the standard library, yes.  The standard library should have external visibility by default.
>>> 
>>> Perhaps you want something like -fvisibility-inlines-hidden that also applies to .
>>> 
>> In principle the fix for PR30066 should allow that when the function templates are explicitely inlined.
>> The point is that many std functions are NOT explicitely declared inline and therefore are not affected by -fvisibility-inlines-hidden.
>> 
>> I want to stress that my concern in not about the public standard interfaces, more about implementation details
>> such as :__introsort_loop, _move_median_first, the back-tree implementation behind std:map etc.
>> At the moment they can even be specialized and "pre-empted" by the user in a different shared library
>> (see discussion in http://sourceware.org/bugzilla/show_bug.cgi?id=12919) and I'm not really sure that this was the intention.
> 
> I don't think the intention is to support pre-emption, but the
> intention is that there's only one definition of entities in the
> standard library.  There are a few functions (particularly in
> mt_allocator, pool_allocator, bitmap_allocator) which use local static
> variables. They might be implementation details, but hiding them could
> cause pretty nasty bugs where two threads in different shared
> libraries both initialize the allocator at the same time, because they
> are using two different pthread_once_t objects.
> 
> Those functions could (and probably should) be marked
> externally_visible, but the point is they aren't today
I noticed. Indeed they need to be made "default visible".
I think one should review all "static" declareation in include/c++/.… and add explicit visibility everywhere is needed.
In any case the classes you mentioned are not striclty speaking part of the stardard, users have the responsibility to explicitly make use of them.
(Personally I have the tendency to make a copy and modify allocators to best fit my needs)

vincenzo

> and so the
> result you want is not as simple as just removing the default
> visibility attributes.