Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?

Subject: Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2011-02-08 05:42:58

On Tue, 08 Feb 2011 15:22:53 +0500, Alexander Arhipenko  
<arhipjan_at_[hidden]> wrote:

> On Mon, Feb 7, 2011 at 6:46 PM, John Maddock <boost.regex_at_[hidden]>  
> wrote:
>>
>> And another thing... ;-)
>>
>> Can someone please explain what's wrong with changing  
>> BOOST_SYMBOL_IMPORT to
>> __attribute__((visibility("default"))) ?
>
> Hi John,
>
> One question:
> what is wrong with having BOOST_SYMBOL_IMPORT defined as it is?
> The only issues we can have is the "malfunctioning exceptions" and
> "mulfunctioning dynamic_cast" operator. To overcome these, symbols
> should be re-exported.
> Could you please provide some motivation to changing BOOST_SYMBOL_IMPORT?
>
> I have 2 objections to changing BOOST_SYMBOL_IMPORT macro definition.
> But these are my own assumptions and I don't insist on it being 100%  
> correct.
>
> The first objection is related to ABI.
> Assume following case:
> I have shared library A build with hidden visibility.
> This library uses almost all of boost dsos: filesystem, system, regex,
> datetime etc
> (this could be real-life scenario). These libraries are used as
> implementation detail.
> Assume boost version is 1.46.
> Assume we are changing BOOST_SYMBOL_IMPORT to "default" visibility in  
> 1.47.
> After I recompile library A with boost 1.47
> I have myriads of new symbols in library A binary interface.
> For someone it will be significant drawback.
> Ok, library A (built with boost 1.47) was used in different
> "production" projects.
> After that, in the new release of library A:
> some critical bug-fixes were implemented;
> dependency on boost.regex was removed.
> But the binary compatibility was lost at this point.
> It was lost because I simply changed implementation detail.
> Another significant drawback.
>
> The second objection is performance.
> The more symbol dso exports (and the higher average symbol length is)
> the more time is spent during library startup.
> Imagine example described above.
> I'm sure it will be noticeable to users that library A
> built with latest boost version (that is assumed
> to change BOOST_SYMBOL_EXPORT macro), loads significantly longer.
> You can also refer to dsohowto document by Ulrich Drepper.
> There is a nice example about OpenOffice.org software package.
> This example shows how decreasing exported symbol count
> could lead to improvement in startup times.

Could you compile with -fvisibility-ms-compat and what problems does it  
have?