Re: [boost] gcc visibility support

Subject: Re: [boost] gcc visibility support
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-07 17:16:13

Andrey Semashev wrote:

> Vladimir Prus wrote:
>> Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114), Jürgen has
>> provided a patch to add gcc visiblity support to all separately compiled libraries.
>> gcc visibility is a mechanism similar to dllexport on Windows, with the same
>> benefits.
>> 
>> I have tried to apply it, and rebuild program_options. The the size of release
>> shared library went from 272K down to 224K. The number of relocations went
>> from 972 to 872. Both changes seem to be good.
> 
> For the record, there was a discussion about visibility support and the
> patch:
> 
> http://lists.boost.org/Archives/boost/2008/12/146068.php
> 
> Last time I heard the patch broke program_options.

It appears to work now, though. I suspect this is because every exception
in boost/program_options/errors.hpp is already marked with
BOOST_PROGRAM_OPTIONS_DECL.

>> It seems to be unlikely to get the authors of every compiled library to
>> look at the patch, so it looks like an alternative approach is necessary.
>> Does anybody have any objections to this approach? If not, I'll check
>> this in somewhere before Jule 15 deadline, and will take care of checking
>> regression results afterwards.
> 
> Perhaps we could search for exception classes and mark them as exported
> right away? We could do this, e.g., by looking for throw_exception or
> throw expressions. A lot of work, I know, but it has to be done anyway.

Hmm, isn't every exception class supposed to be marked with BOOST_XXX_DECL
anyway? 

 
> Maybe there are other procedures necessary to make sure it works.
> Boost.Exception comes to mind as a possible source of issues. It is
> related to both exceptions and dynamic_cast. I'm guessing, at least
> error_info should be exported, too.

I am unsure why -- it is ever used where typeid matters?

- Volodya