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 17:30:55

On Wed, May 19, 2010 at 11:56 AM, John Maddock <boost.regex_at_[hidden]> wrote:

> FYI, there is an open ticket on this:
> https://svn.boost.org/trac/boost/ticket/2114 which still requires some work
> (mostly tests and updated docs) before rolling out.

As Jürgen points out, that's one of the three or four open tickets we
are trying to resolve.

>...
>> If you use BOOST_SYMBOL_EXPORT, VC++ will warn because
>> __declspec(dllexport) isn't valid in this context. If you don't
>> decorate my_exception at all, VC++ is happy, but GCC shared libraries
>> compiled with -fvisibility=hidden can't successfully throw exceptions
>> up to callers outside the shared library. The only way around that I
>> can see is to use a separate macro that is only defined for GCC.
>
> 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++.

I've tried VC++ with __declspec(dllexport), __declspec(dllimport), and
BOOST_SYSTEM_DECL (which will be __declspec(dllexport) or
__declspec(dllimport) depending on the context.

Surprisingly, __declspec(dllexport) is the only decoration that passes
all Boost.System tests. But all of the decorations tested produce VC++
warning messages.

>  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
> :-(

While I didn't run into that particular problem, Boost.System has
minimal needs. One of the advantages of introducing a separate macro
is that it won't be present for most compilers, including VC++. Thus
only GCC will actually get any decoration, so there will be no
warnings or other unintended consequences for other compilers.

--Beman