Re: [boost] support for gcc hidden visibility in shared libraries

Subject: Re: [boost] support for gcc hidden visibility in shared libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-12-05 14:12:32

Stjepan Rajko wrote:
> Hello,
> 
> To my limited understanding, making a symbol visible in a shared
> library using, say, __attribute__ ((visibility("default"))) on gcc, is
> analogous to using __declspec(dllexport) on windows.   Many boost
> libraries already use macros that apply  __declspec(dllexport) on
> windows - so these macros could set to expand to __attribute__
> ((visibility("default"))) on gcc.  Even better, a boost-wide macro
> could be added to the config headers.

Visibility attribute has notable differences compared to dllexport. For
example, all type_info's must be made externally visible in order to
have dynamic_cast, exceptions and type_info comparison working (one of
the most striking affected libraries is Boost.ProgramOptions, since it
is built on top of Boost.Any, which uses type_info).

Also, it affects ODR adherence across modules. E.g. with default
visibility "hidden" an address of the same function or global variable
may appear to be different in different modules. This is already the
case on Windows, though, so I guess this change should not break
anything, but still it should be taken into account.

So it doesn't look like a trivial change in settings and macros to me.
What's worst, making such a change can trigger problems that are hardly
detected by unit tests. Perhaps, we should just mandate the
visibility=hidden mode not supported for now. Maybe
--fvisibility-ms-compat or --fvisibility-inlines-hidden would be a
better choice to support?