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

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Alexander Arhipenko (arhipjan_at_[hidden])
Date: 2010-05-20 09:54:26

On Thu, May 6, 2010 at 7:42 PM, Jürgen Hunold <juergen.hunold_at_[hidden]> wrote:
> Hi Beman,
>
[snip]
>
> I've got a working patch set lying around. Please find it attached.
> Real life got in the way (as usual)...
>
> The patch introduces two Boost.Config macros
> - BOOST_SYMBOL_EXPORT
> - BOOST_SYMBOL_IMPORT
>
> for Windows and gcc > 4.
> Those lack the needed test cases at the moment (lack of time on my side).
> The patch replaces
> __declspec(dllexport) with BOOST_SYMBOL_EXPORT
> __declspec(dllimport) with BOOST_SYMBOL_IMPORT
> and removes visibility declarations from forward declarations in order to
> eliminate gcc warnings. msvc does not care, but does only need visibility
> information when the class in declared.
> Tested with
> - gcc-4.3, 4.4, 4.5
> - msvc 9.0
>
> I can do a msvc 10.0 run if needed.
>
>> It would be better is discussion could occur on this list, rather than
>> as comments attached to the ticket. That will ensure more eyeballs
>> look at this.
>
> Yes, please take a careful look at the patch.
>

Hi Jurgen, boosters,

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.

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

Regards