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

Subject: Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
From: Alexander Arhipenko (arhipjan_at_[hidden])
Date: 2011-02-08 05:22:53

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.

>
> Surely the only things that GCC can re-export in that case is RTTI info and
> class vtables (it doesn't have access to member function definitions after
> all only declarations) - and that's exactly what we want to happen right?
> For sure we may re-export some symbols that end up not being used, but in
> principle a shared library cannot know in advance what it's clients will use
> / need anyway?
>
> Sorry if I'm being dense.
>
> Cheers, John.
>

Regards and good luck