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
>Â 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk