Subject: Re: [boost] support for gcc hidden visibility in shared libraries
From: Othman, Ossama (ossama.othman_at_[hidden])
Date: 2008-12-05 14:34:43
>Visibility attribute has notable differences compared to dllexport. For
>example, all type_info's must be made externally visible in order to
>have dynamic_cast, exceptions and type_info comparison working (one of
>the most striking affected libraries is Boost.ProgramOptions, since it
>is built on top of Boost.Any, which uses type_info).
>Also, it affects ODR adherence across modules. E.g. with default
>visibility "hidden" an address of the same function or global variable
>may appear to be different in different modules. This is already the
>case on Windows, though, so I guess this change should not break
>anything, but still it should be taken into account.
>So it doesn't look like a trivial change in settings and macros to me.
>What's worst, making such a change can trigger problems that are hardly
>detected by unit tests. Perhaps, we should just mandate the
>visibility=hidden mode not supported for now. Maybe
>--fvisibility-ms-compat or --fvisibility-inlines-hidden would be a
>better choice to support?
I've run into problems with the latter where RTTI would break if all intermediate base classes with virtual destructors did not explicitly define one, e.g.:
class EXPORT Base
class EXPORT Intermediate : public Base
// No explicitly defined virtual destructor.
class EXPORT Derived : public Intermediate
A dynamic_cast<> from Base to Derived would fail unless the ~Intermediate() destructor was explicitly defined, presumably out-of-line.
The last time I experimented with gcc visibility support was a couple of years ago. Perhaps this subtle issue has been addressed or at least improved since then.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk