What to do? Mac, hidden visibility, and Boost
Posted: Thu Jun 01, 2017 11:56 am
I've reached an impasse for the Mac build. I need to hear what steps the FO group want to take next.
The FO code is compiled with "-fvisibility=hidden", which really means that the SDK libraries should also be built that way too. (In for a penny, in for a pound.) I've been working on that.
I've come across a case that I think can only be resolved by either turning off the "-fvisibility=hidden" flag when compiling the code, or by hacking one of the Boost files with a patch. adrianbroher has stated strongly that user patches are not an option (no "local garbage"), but I don't see another solution that will retain hidden visibility.
I need feedback.
Do we drop visibility=hidden, am I allowed an exception to use a home-grown SDK patch for this one specific issue, or is there another solution that I'm not seeing?
--The Details--
Looking through the online discussions, Boost has visibility issues which are being resolved, but most of that work is on the Windows side. The "iostreams" library does not have a solution for non-Windows builds.
For the Mac, with the libraries and FO code using visibility=hidden, the code cannot find "boost::iostreams::zlib::default_compression". This is defined in iostreams/filter/zlib.hpp as
The only place that BOOST_IOSTREAMS_DECL is defined is iostreams/detail/config/dyn_link.hpp
That file sets the macro to either Windows-specific settings (declspec(dllexport)), or leaves it blank.
(That file is the same in both versions 1.59 and the recent 1.64.)
So the Boost iostreams library will have the wrong visibility settings.
This is unlike other places in the Boost code, where it is possible to get the right visibility settings by defining the library DECL macro as BOOST_SYMBOL_EXPORT. (Take a look at filesystem/config.hpp as an example of how it is done for most of the other libraries.)
The FO code is compiled with "-fvisibility=hidden", which really means that the SDK libraries should also be built that way too. (In for a penny, in for a pound.) I've been working on that.
I've come across a case that I think can only be resolved by either turning off the "-fvisibility=hidden" flag when compiling the code, or by hacking one of the Boost files with a patch. adrianbroher has stated strongly that user patches are not an option (no "local garbage"), but I don't see another solution that will retain hidden visibility.
I need feedback.
Do we drop visibility=hidden, am I allowed an exception to use a home-grown SDK patch for this one specific issue, or is there another solution that I'm not seeing?
--The Details--
Looking through the online discussions, Boost has visibility issues which are being resolved, but most of that work is on the Windows side. The "iostreams" library does not have a solution for non-Windows builds.
For the Mac, with the libraries and FO code using visibility=hidden, the code cannot find "boost::iostreams::zlib::default_compression". This is defined in iostreams/filter/zlib.hpp as
Code: Select all
BOOST_IOSTREAMS_DECL extern const int default_compression;
That file sets the macro to either Windows-specific settings (declspec(dllexport)), or leaves it blank.
(That file is the same in both versions 1.59 and the recent 1.64.)
So the Boost iostreams library will have the wrong visibility settings.
This is unlike other places in the Boost code, where it is possible to get the right visibility settings by defining the library DECL macro as BOOST_SYMBOL_EXPORT. (Take a look at filesystem/config.hpp as an example of how it is done for most of the other libraries.)