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
#if (defined(BOOST_AFIO_DYN_LINK) || defined(BOOST_ALL_DYN_LINK)) &&
# if defined(BOOST_AFIO_SOURCE)
# undef BOOST_AFIO_HEADERS_ONLY
# define BOOST_AFIO_DECL BOOST_SYMBOL_EXPORT
# define BOOST_AFIO_BUILD_DLL
# define BOOST_AFIO_DECL
# 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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk