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