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.