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

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-02 14:21:16

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.

> From the BOOST_SYMBOL_VISIBLE description: "Needed for classes that are
> not otherwise exported, but are used by RTTI". This sounds to me like
> either a BOOST_SYMBOL_EXPORT or BOOST_SYMBOL_IMPORT should work.
> Now I'm left to wonder why individual libraries must now distinguish
> between OSes additionally to their *_DYN_LINK.

I suggest reading the GCC visibility guide again. You appear to be
conflating how ELF does things, and how everything-except-ELF does things.

We have a hacky, poor quality, map of everything-except-ELF DLL
import/export semantics onto the much inferior, and quite broken, ELF
semantics. It works well enough, most of the time, if you are 100%
perfect in avoiding all the poorly documented footguns. But let me be
clear, what Windows, MachO, everything-except-ELF do is the *correct*
design. What ELF does is a travesty to writing production quality code.
But things are what they are.

I completely agree that this sucks, and you'd think fifteen years of
footgun pain would make someone fix it. But solving this is a political,
not engineering, problem and it went beyond my personal reserves of
patience and forebaring.

> And if Boost.Config is correct: What does BOOST_SYMBOL_IMPORT (on
> non-Windows) mean then? If the default visibility is set to hidden
> (-fvisibility=hidden), then this macro will NOT import an exported
> symbol, it will create a new, private one.
> This doesn't sound intentional.

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

Niall