Re: [boost] support for gcc hidden visibility in shared libraries

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
>> BOOST_SYMBOL_EXPORT etc
>>    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 boost.build expert, so this patch
>> supposed to be
>> rather *ugly* and should be carefully reviewed by some boost.build guy.
>>
>> The second patch affects all the boost configuration files with
>> BOOST_XXX_DECL macroses:
>> __declspec(dllexport)/(dllimort) are simply replaced with macroses
>> BOOST_SYBMOL_EXPORT/IMPORT.
>>
>> 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
>> BOOST_CHECK_THROW:
>> 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.