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 11:30:40

On Thu, May 20, 2010 at 9:54 AM, Alexander Arhipenko <arhipjan_at_[hidden]> wrote:
> On Thu, May 6, 2010 at 7:42 PM, Jürgen Hunold <juergen.hunold_at_[hidden]> wrote:
>> Hi Beman,
>>

> Some comments on patch.
>
> 1)
> 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.
>
> In case when __attribute__((visibility("default")) is always defined,
> foo's ABI contains boost filesystem's exported symbols also.
> In case if BOOST_SYMBOL_EXPORT/IMPORT macros defined as above,
> foo's ABI contains only it's own exported symbols.
>
> In my opinion, shared library ABI should not contain any
> implementation details.
> So, I would rather vote for using export/import macros defined as above.
> Please, correct me if I'm wrong or misunderstood something.

My patch was based on Jürgen's original " #define
BOOST_SYMBOL_IMPORT". We need to get input from him as to why that
changed in his second patch.

>
> 2)
> What do you think about having BOOST_SYMBOL_EXPORT/IMPORT always defined?
> This will decrease #ifdef branches in libraries configuration files
> (config.hpp).

I just tried that on <boost/system/config.hpp>, and it is quite a bit
shorter (12 loc vs 19 loc), reads better, and is probably easier to
teach. So unless someone objects, I'll follow your suggestion.

Thanks,

--Beman