On 7 May 2015 at 16:40, Andrey Semashev wrote:
Is it possible to add a tester that enables hidden visibility (- fvisibility=hidden -fvisibility-inlines-hidden) when building and testing Boost? I believe, a single tester on Linux+GCC would be enough to discover most issues related to symbol visibility.
The reason I'm asking is that I believe Boost should support building with hidden visibility by default. This mode allows more optimizations and does not export unintended symbols from libraries.
I've set hidden visibility for Boost.Log (in develop) and, as I understand, Robert is doing a similar change in Boost.Serialization. However, when building 1.58 with hidden visibility for my project I found out that not all libraries work well with that setting.
What do you think about it?
Many years ago when Dave Abrahams asked me to contribute visibility support to Boost he hoped to persuade all library maintainers to add support and for all libraries to be built with default hidden visibility such that ELF shared objects gained some of the reuse stability of PE DLLs. At the time such a move was controversial and considered retrograde by a sufficient proportion of C++ experts, and so that effort never panned out. Dave, at that time, was irritated by this attitude if I remember correctly. Now everyone is much more comfortable with the idea of actively managing shared library coupling at the binary level, I think there is a chance that flipping hidden visibility on for all Boost.Build and forcing maintainers to finally do the right thing in their libraries is very worth considering. After all, most libraries now support Windows DLLs, and if you already support Windows DLLs it's a very small addition to support ELF symbol export. Just follow the instructions at https://gcc.gnu.org/wiki/Visibility using this as a template: #if (defined(BOOST_AFIO_DYN_LINK) || defined(BOOST_ALL_DYN_LINK)) && \ !defined(BOOST_AFIO_STATIC_LINK) # if defined(BOOST_AFIO_SOURCE) # undef BOOST_AFIO_HEADERS_ONLY # define BOOST_AFIO_DECL BOOST_SYMBOL_EXPORT # define BOOST_AFIO_BUILD_DLL # else # define BOOST_AFIO_DECL # endif #else # define BOOST_AFIO_DECL #endif // building a shared library ... and then markup all public types and functions with a BOOST_AFIO_DECL. And make sure when building your library BOOST_AFIO_SOURCE is defined. Done. On 7 May 2015 at 7:54, Robert Ramey wrote:
So I had to update the source code to support the attributes for symbol export on those functions which need to be exported. It sounds simple, but getting this right in a way that supports both gcc and MSVC is tricky and hard to get correct. I got the gcc to build and pass all test, but now the MSVC is broken. Unfortunately, our testing system truncates the error message so I can't see why the current branch in develop fails to build. I'm still waiting from a response from the boost build team.
I have no idea why you continue to insist on trying to second guess the very well established pattern here. The design of the GCC visibility support was chosen back in 2004 to correctly support all combinations of GCC, MSVC and Mingw without any special casing, trickery, or any macro work above the traditional preprocessor logic used for MSVC. One macro system for marking up export/import. Same system for all compilers. Easy, if you make it easy on yourself. Just reuse, without addition, what works on MSVC to build DLLs. Mark up exception throwable types with BOOST_SYMBOL_VISIBLE so clang works. Done. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/