Re: Wrong class export/visibility setting for shared libs in many Boost libs

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-02-02 14:43:37

Am 02.02.21 um 15:21 schrieb Niall Douglas via Boost:
> On 02/02/2021 14:06, Alexander Grund via Boost wrote:
>
>> Why do individual libraries now have to deal with the Windows vs
>> non-Windows case? Is there ANY Boost library which does this?
> Outcome is correct on this. I think any of Dave's original libraries are
> correct on this, or at least, were once.
Ok, found an exception class there: 
https://github.com/boostorg/outcome/blob/15ec857dd65dfbb710d33bd567ee3f14c62009e2/include/boost/outcome/bad_access.hpp#L43

It is marked with BOOST_SYMBOL_VISIBLE, so we seem to agree, that this 
is required for all user visible classes that are errors/exceptions or 
virtual (and hence might be subject to dynamic_cast)
So this leaves the IMPORT/EXPORT only for classes, which are non-virtual 
and have non-inline members.

Correct so far?

What about classes, which have a non-inline function, e.g. the recently 
mentioned exception class with a non-inline `what()`?
Wouldn't that need to be IMPORT/EXPORT declared for Windows? And VISIBLE 
for Linux (to be caught)? So would you need both here?

> Hidden symbols are subject to much more aggressive optimisation than
> default visibility symbols. So yes, this is intentional.

I'm aware of that. But I'm looking for a correct solution, i.e. one that 
works across platforms. That it seemingly works on Linux seems to be 
caused by a change to string comparison instead of "real" RTTI 
comparison. The question is: Should it work, or has it always worked?
I mean we have one TU (in the shared lib) where the symbol is visible 
and one (in the exe) where it is not. So how could the RTTI here be the 
same?