Re: [boost] [testing] Add a tester with hidden visibility

Subject: Re: [boost] [testing] Add a tester with hidden visibility
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-07 11:45:22

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/