Guys, I've decided to start a new thread on this topic. The messages beyond was taken from the last ticket comments.
--------------------------------------------------------------------- *** Changed 19 hours ago by johnmaddock *** ---------------------------------------------------------------------
Is this nearly ready to go in Trunk now?
Before it does at the very least we need:
1) An update for http://www.boost.org/development/separate_compilation.html 2) An update for the Boost.Config docs for each of these new macros. 3) A clear understanding of what BOOST_SYMBOL_FORWARD_EXPORT/IMPORT do. 4) A clear understanding of what needs re-exporting - IMO BOOST_EXCEPTION_EXPORT is somewhat misleading since as I understand the gcc docs this may need to be applied to any class that has "vague linkage" whatever that is. Also do we need to re-export std lib exceptions from our SO's? Do we have a dependency analysis to know when we need to use these (or that we don't need to)?
John.
----------------------------------------------------------------- *** Changed 3 hours ago by arhipjan@… *** -----------------------------------------------------------------
Replying to johnmaddock:
JFYI, stdcxx library (at least of version 4.1.1 and later) already have default visibility for std::exception, std::bad_exception, i.e:
//exception header
#pragma GCC visibility push(default)
namespace std {
class exception {/*...*/}; class bad_exception {/*...*/};
//...
Also logic_error, runtime_error don't cause abnormal program termination since they have key functions (i.e. at least one non-inline virtual function).
--------------------------------------------------------------------- *** Changed 26 minutes ago by anonymous *** ---------------------------------------------------------------------
I forgot one other requirement: we should maybe try and put together a small test case to check that this all works.
Good to hear that libstdc++ already does the necessary work, does this mean that exceptions that inherit from std::runtime_error (as I think all Boost >exceptions do?) are automatically visable and don't need re-exporting on account of their virtual functions?
Oops, one other thing (sorry!), how if at all is Boost.Exception effected by this - especially as it's header only?
Cheers, John.
I would like to make some comments: 1) BOOST_EXCEPTION_EXPORT macro In current patch version there is no need for this macro, since all the symbols marked with BOOST_SYMBOL_EXPORT always have default visibility on gcc. (In the original version, they have default visibility when building shared library and hidden visibility when using it in another shared library). 2)
Also do we need to re-export std lib exceptions from our SO's?
JFYI, stdcxx library (at least of version 4.1.1 and later) already have default visibility for std::exception, std::bad_exception [snip] Also logic_error, runtime_error don't cause abnormal program termination since they have key functions (i.e. at least one non-inline virtual function).
Good to hear that libstdc++ already does the necessary work, does this mean that exceptions that inherit from std::runtime_error (as I think all Boost exceptions do?) are automatically visable and don't need re-exporting on account of their virtual functions?
The exceptions that inherit std::exception (or std::runtime_error) are not visible. But throwing such exception from shared library and catching it in another exe or lib doesn't cause abnormal termination (but only if thrown exception have at least one key function)