[config] BOOST_SYMBOL_VISIBLE on MinGW
I made adjustments so that the serialization library on Develop branch will build with default visibilty = hidden. There is a little more to this than one would think. Basically I used BOOST_SYMBOL_VISIBLE on all "exported" classes (and their base classes) and BOOST_ARCHIVE_DECL ( defined as either BOOST_ARCHIVE_IMPORT or BOOST_ARCHIVE_EXPORT) on exported/visible member functions. This seems to give me what I need in that things build and test for gcc, clang, MSVC. EXCEPT for gcc under MinGW. see http://www.boost.org/development/tests/develop/developer/output/MinGW-32%20j... The message seems to indicate to me that I should have BOOST_SYMBOL_VISIBLE on the class declaration - which seemed to resolve similar compilation errors with GCC on other platforms. Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems to me that this scheme things look OK - that is it looks that BOOST_SYMBOL_VISIBILITY should be defined as __attribute__((__visibility__("default"))) I'm also puzzled by the fact that the linker craps out only on this on declaration. Any help appreciated. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-BOOST-SYMBOL-VISIBLE-on-MinGW-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 16 Apr 2015 at 8:07, Robert Ramey wrote:
Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems to me that this scheme things look OK - that is it looks that BOOST_SYMBOL_VISIBILITY should be defined as __attribute__((__visibility__("default")))
I'm also puzzled by the fact that the linker craps out only on this on declaration.
Any help appreciated.
You're second guessing the established pattern for how to do symbol visibility. The established patterns were chosen for good reasons. In particular, the established pattern works as expected on Mingw, MSVC and all other compilers. Per member function overrides are particularly unwise to do. Assuming you can't be dissuaded from this path, I'd suggest you examine very closely indeed the dump of exported symbols from shared libraries using the nm tool and make very sure they do not export a brittle mish mash of symbols in a way highly likely to cause unexpected problems for your users. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote
On 16 Apr 2015 at 8:07, Robert Ramey wrote:
Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems to me that this scheme things look OK - that is it looks that BOOST_SYMBOL_VISIBILITY should be defined as __attribute__((__visibility__("default")))
I'm also puzzled by the fact that the linker craps out only on this on declaration.
Any help appreciated.
You're second guessing the established pattern for how to do symbol visibility.
How so?
The established patterns were chosen for good reasons.
I did look over the boost documentation on the usage of the auto-link/visibility macros along with the source code in config and the email chain which discussed all this in some detail. Frankly, I've been able to find and explanation of what "established patterns" are.
In particular, the established pattern works as expected on Mingw, MSVC and all other compilers. Per member function overrides are particularly unwise to do.
I don't see how to avoid this if one needs to use BOOST_SYMBOL_VISIBLE for exported class declarations to satisfy gcc. Hmm - things have worked well for many years for mdvc and Borland (now obsolete). I made a few changes to support gcc visibility and after a couple of hiccups, things work with Gcc as well. Seems to me that mingw is some combination of compiler=gcc and platform = win32. I'd be curious to hear from anyone who might have had a similar issue and resolved it. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-BOOST-SYMBOL-VISIBLE-on-MinGW-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (2)
-
Niall Douglas -
Robert Ramey