Re: [boost] [all] Request for out of the box visibility support

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-18 17:26:16

On 08/18/18 18:19, Robert Ramey via Boost wrote:
> On 8/18/18 6:58 AM, Edward Diener via Boost wrote:
>>
>> I do not see any difference, vis-a-vis the visibility problem 
>> discussed, between dynamically loaded shared libraries or statically 
>> loaded shared libraries. 
> 
> visibility isn't really an issue with static libraries. visibility 
> decreases the number of externally visible symbols.  In linking a static 
> library this might decrease linking times - but I haven't noticed it and 
> I never received complaints about it.

Visibility in static libraries doesn't affect linking times (i.e. 
linking as the building stage, not the binary loading stage) because 
hidden symbols are used in symbol resolution. But visibility markup is 
still important in static libraries because it is preserved when the 
final executable is produced. So, for example, if you mark a type with 
default visibility and define it in a static library, you can link that 
library into a shared library and the type would still be 
default-visible*. This is useful when you want to ensure that a certain 
type, like an exception, is public regardless of how it is compiled into 
the final executable.

* I'm ignoring here linker scripts, which can further hide symbols on 
the linking stage. AFAIK, we don't use linker scripts in Boost, but some 
applications do.

>Â  I think that the BOOST visibility 
> macros are defined to nothing for static builds.

No, BOOST_SYMBOL* macros are defined the same way regardless of the build.

> But for shared libraries it's a whole 'nuther issue.  The huge number of 
> symbols in libraries can make the shared libraries much, much larger and 
> slow down dynamic linking time considerably.  This is why this is a 
> worthy project.

More importantly, hiding internal symbols ensures there won't be a 
symbol clash. This is also a security matter.

>  From personal experience in implementing this for the serialization 
> library (admittedly a more complex example), anyone who embarks upon 
> this will be disappointed at the amount of time it ends up consuming.

I suspect there may be a lot of specifics in Boost.Serialization. 
However, most of the time supporting hidden visibility is quite 
straightforward and goes in line with supporting dllexport/dllimport on 
Windows.