Re: [boost] support for gcc hidden visibility in shared libraries

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

Hi,

>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
{
public:
  ...
  virtual ~Base();
  ...
};

class EXPORT Intermediate : public Base
{
   ...
   // No explicitly defined virtual destructor.
};

class EXPORT Derived : public Intermediate
{
public:
   ...
   virtual ~Derived();
   ...
};

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.

HTH,
-Ossama