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

Subject: Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-02-08 08:15:19

> 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?

It's to fix those two issue.

Note that as library authors *we have no way of knowing when re-export is 
required*, but re-export requires a change to *our headers*.

That's the fundamental issue we're trying to solve.

> 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.

Nod, good points, I think that's a real 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.

Sure, the question I'm still looking for someone to answer, is "what does 
re-exporting actually do to increase startup bloat"?  Remember the .so 
that's doing the re-exporting doesn't have access to the definitions of 
re-exported classes, only the declaration.  So presumably (based on no 
evidence at all!) only RTTI info for polymorphic classes will be 
re-exported, which is pretty much what we want to have happen anyway?

OK, I see these options:

1) Do nothing, have the user set whatever macro is used to control 
*exporting* symbols from a Boost .so when they want to re-export that lib.
2) Do almost nothing, but have a Boost-wide macro that changes dll-import to 
default visibility, and re-export all Boost symbols.
3) Re-export all imported symbols by default, but have a way to turn that 
off.

What I'm trying to avoid is:

4) Fine grained macros that give different visibility to different symbols - 
we have enough trouble keeping this all working as it is!

Thoughts?

John.