Re: [boost] [config] GCC symbol visibility across shared libraries

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-05-20 10:53:08

On Thu, May 20, 2010 at 10:21 AM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> Alexander Arhipenko
>> On Thu, May 6, 2010 at 7:42 PM, Jürgen Hunold wrote:
>> >
>> > The patch replaces
>> > __declspec(dllexport) with BOOST_SYMBOL_EXPORT
>> > __declspec(dllimport) with BOOST_SYMBOL_IMPORT
>> > and removes visibility declarations from forward
>> > declarations
>>
>> The first version of BOOST_SYMBOL_EXPORT/IMPORT macro
>> had slightly different definition for gcc (something like this):
>> #define   BOOST_SYMBOL_EXPORT  __attribute__((visibility("default"))
>> #define   BOOST_SYMBOL_IMPORT
>>
>> Assume that I've built boost filesystem library with hidden
>> visibility.
>> After that I've used boost filesystem functionality in my custom
>> shared library foo (also build with hidden visibility).
>> Assume also that boost filesystem was used as an
>> implementation detail.
>> You will never find any references to filesystem in foo's
>> public interface.
>
> Each dynamic library should define its own import/export macro to adorn the symbols of that library that should be exported/visible.  Those macros should be based upon BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT and whether the dynamic library is being built or used:
>
> #ifdef BUILDING_MYLIB
> #  define MYLIB_EXPORT BOOST_SYMBOL_EXPORT
> #else
> #  define MYLIB_EXPORT BOOST_SYMBOL_IMPORT
> #endif
>
> Using MYLIB_EXPORT for all public symbols in MyLib, and defining BUILDING_MYLIB only when compiling MyLib, will do what you want.

See http://svn.boost.org/trac/boost/wiki/Guidelines/Separate for the
current guidelines, which most Boost libraries seem to be following.

Thus for Boost.System, the name for the macro is BOOST_SYSTEM_DECL

We aren't proposing any change to that; I think both Jürgen and I were
trying to make fairly minimal changes to current Boost practice and
headers.
>
> Arguably, "EXPORT" in "MYLIB_EXPORT" is misleading, at least for MyLib's clients.  Perhaps "MYLIB_VISIBLE" is a better name, leaving BOOST_SYMBOL_VISIBLE, or whatever it may be called, for the non-import/export cases.
>
>> 2)
>> What do you think about having BOOST_SYMBOL_EXPORT/IMPORT
>> always defined?
>
> If that's not what's being done -- I haven't looked at the patch itself -- then I agree.  Those macros should always be defined and each library must decide which to use as shown above.

At the moment that isn't being proposed. I'm not against doing that,
and considered always defining all three of the new macros
(BOOST_SYMBOL_EXPORT/IMPORT/VISIBLE). That would imply changing all
compiler config headers, so I'd need help getting them right for
compilers I'm not familiar with.

Let me look at the impact of that change on library code before making
any final decision.

--Beman