Re: [boost] [config] GCC symbol visibility across shared libraries

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-05-20 10:22:08

On Thu, May 20, 2010 at 7:23 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Beman Dawes wrote:
>> On Wed, May 19, 2010 at 9:55 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> > Beman Dawes wrote:
>> >> On Thu, May 6, 2010 at 12:42 PM, Jürgen Hunold
>> >> <juergen.hunold_at_[hidden]> wrote:
>> >>
>> >> > The patch introduces two Boost.Config macros
>> >> > - BOOST_SYMBOL_EXPORT
>> >> > - BOOST_SYMBOL_IMPORT
>> >>
>> >> AFAICT, a third macro is needed for GCC. I've named it
>> >> BOOST_SYMBOL_VISIBLE and define it as
>> >> __attribute__((visibility("default")))
>> >>
>> >> The need for this macro arises in header only classes like this:
>> >>
>> >>     class BOOST_SYMBOL_VISIBLE my_exception
>> >>        : public std::runtime_error { ... };
>> >>
>> >> If you use BOOST_SYMBOL_EXPORT, VC++ will warn because
>> >> __declspec(dllexport) isn't valid in this context.
>> >
>> > I don't understand the problem in that case.
>>
>> At the least, you this warning:
>>
>> c:\boost\trunk\boost\system\system_error.hpp(26) : warning C4275: non
>> dll-interface class 'std::runtime_error' used as base for
>> dll-interface class 'boost::system::system_error'
>
> I hate that warning!
>
>> But for one of the Boost.System tests, VC++ gets so confused that it
>> fails to inline the functions defined in the class, and you get a
>> bunch of unresolved externals.
>
> Wow!

Yeah, this is really bad. My guess is that this is an example of the
case a couple of folks mentioned could require decorating members with
declspec. Much better to not decorate at all for VC++ IMO.

> Let me get this straight, then.  Since the class is header only, it needn't be exported from a DLL, hence using dllexport is wrongheaded for MSVC.  However, GCC's -fvisibility=hidden interferes because of the need to explicitly mark exception types as visible.  Have I got things right so far?

Yes, but it isn't just exception types.
>
> Is there any other case in which a symbol must be marked visible explicitly where BOOST_SYMBOL_EXPORT is not appropriate?

IIUC, what is actually at stake is whether RTTI info is visible. So it
apparently also impacts things like static members of a class template
and certain dynamic_casts.

See http://gcc.gnu.org/wiki/Visibility, particularly the section
"Problems with C++ exceptions (please read!)".

But be aware that I'm just feeling my way through this - I'm not
primarily a UNIX, Posix, or GCC programmer so don't have even
superficial knowledge of how shared libraries work in that
environment.

>  If not, BOOST_SYMBOL_VISIBLE is the wrong name.  It should be BOOST_VISIBLE_EXCEPTION_TYPE or something like that to be clear that it is for use with exception types only.

Apparently the problem is wider that just exception types:-)

I'm not wedded to BOOST_SYMBOL_VISIBLE. It seemed to work with
BOOST_SYMBOL_EXPORT/IMPORT, but I'm not wedded to those either. But
they seem appropriate, and I didn't see any reason to deviate from
Jürgen's patch.

Thanks for the comments,

--Beman