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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk