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.