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?