Boost logo

Boost :

Subject: Re: [boost] support for gcc hidden visibility in shared libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-12-17 13:15:32

Alexander Arhipenko wrote:
> On Thu, Dec 11, 2008 at 3:54 PM, Alexander Arhipenko <arhipjan_at_[hidden]> wrote:
>> Guys, while reading through your fruitful comments, I've became to the
>> following conclusions:
>> 1. We should preserve default behavior of each toolset when building boost,
>> e.g., for gcc compilation should be performed with visibility=default
>> 2. We should give the ability to users:
>> a) simplify build of custom libraries by providing macros such as
>> b) build needed boost library with custom visibility (hidden,
>> ms-compat etc).
>> All this ideas are implemented in attached patches.
>> The first patch is for boost-build.
>> It provides new composite feature 'hide-symbols' with available options:
>> on, off, ms-compat, inlines-hidden.
>> So, if I would like to build filesystem with hidden visibility, I can
>> do the followings:
>> * In boost root directory type "bjam /boost/filesystem hide-symbols=on"
>> * In my library's Jamfile:
>> alias filesystem : /boost/filesystem : <hide-symbols>on ;
>> 'hide-symbols' feature should work only for gcc and darwin toolsets.
>> For the others it does nothing.
>> Unfortunately I had no ability to test darwin.
>> It worth mentioning that I'm not a expert, so this patch
>> supposed to be
>> rather *ugly* and should be carefully reviewed by some guy.
>> The second patch affects all the boost configuration files with
>> BOOST_XXX_DECL macroses:
>> __declspec(dllexport)/(dllimort) are simply replaced with macroses
>> As you may see, attached patches preserve default behavior of boost
>> build procedure.
>> Unit tests.
>> I've performed unit testing for affected libraries (with gcc (GCC)
>> 4.1.2 20071124 (Red Hat 4.1.2-42) ).
>> All of them (except serialization) was built with hidden visibility.
>> It was 2 failures in program_options (as Andrey predicted ;) ) in
>> exception wasn't caught (variable_map_test_dll, unicode_test_dll).
>> All the others run smoothly (unless I missed something).
>> Exceptions.
>> This worries me a lot, since all the exceptions that wasn't *properly
>> exported* will never be caught.
>> Saying *properly exported* I mean:
>> they always have default visibility
>> or
>> have been exported from shared library and have at least one key function,
>> i.e. "non-pure virtual function that is not inline at the point of
>> class definition"
>> To reproduce this issue, you can try to build attached sample project
>> and run ./install/fee_client /some/invalid/path:
>> boost::filesystem_error and boost::system_error won't be caught.
>> (Note, dependent boost libraries should be build with default visibility).
>> Regards
>> P.S. Again, comments and questions will be really apreciated
> Any feedback?

I intended to take a closer look later, but it seems my time is running
too fast.

In general, I'd be inclined to have a somewhat more general switch, like
restrict-visibility=on/off, with "off" being the default. The "on" would
mean different things depending on the compiler. The point is that it
(a) simplifies configuration and (b) allows to keep build settings
consistent through different compiler and Boost versions.

Another point is that I don't think we should add support for "hidden"
visibility in the build configuration until we are sure it is supported
by the code. The tests already highlighted problems and I am not sure
there aren't other issues not covered by tests. Maybe a total code
review is needed to state that we support this mode.

Boost list run by bdawes at, gregod at, cpdaniel at, john at