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-19 18:13:31

On Wed, May 19, 2010 at 3:34 PM, James Mansion
<james_at_[hidden]> wrote:
> John Maddock wrote:
>>
>> Yeh, that's a tricky one, 'cos VC++ will warn almost whatever you do.  I
>> *think* the correct thing to do for header only classes is to mark them as
>> __declspec(dllimport) - that way if you contain or inherit from them in an
>> exported class you won't get more warnings - the main culprit here is
>> noncopyable which is unusable without copious warnings from VC++.  Oh and I
>> think I've had warnings when containing a shared_ptr in an exported class
>> too... in fact come to think of it if I write an exported class like this:
>>
>> class BOOST_SYMBOL_EXPORT foo
>> {
>> private:
>>   some_boost_type member;
>> };
>>
>> Won't I have issues unless "some_boost_type" is declared visible/exported?
>> Bare in mind that this could be practically any template declared in Boost
>> :-(
>>
>> Just thinking out loud yours, John.
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> AMQP changed to decorating the methods themselves (and only the ones
> designed for consumption outside the module) for reasons similar to this.
>  Suggest you talk to Steve Huston, or search the AMQP mail list archive.

We have a very minor problem that apparently can be fixed by the
introduction of one new config macro and will have very little impact
on most Boost libraries. I'd hate to do anything that forces massive
changes like decorating every member. Particularly if the only
practical problem users are running into is failing to catch a
library's exceptions when thrown by GCC across a DSO/DLL boundary.

--Beman