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:06:34

> This means that BOOST_PROGRAM_OPTIONS_DECL is incorrectly defined.
>
<snip>
>
> So, the bottom line, BOOST_PROGRAM_OPTIONS_DECL must be defined to:
>
> - BOOST_SYMBOL_EXPORT - on Windows, when the library is being built;
> - BOOST_SYMBOL_IMPORT - on Windows, when the library is being consumed 
> by user;
> - BOOST_SYMBOL_VISIBLE - in any other case.
>
> Then you can use BOOST_PROGRAM_OPTIONS_DECL to mark methods and 
> classes that you want to be exported/imported from the library. If a 
> particular type does not need to be exported/imported, but whose RTTI 
> must still be accessible across library boundaries, mark that type 
> with BOOST_SYMBOL_VISIBLE, not BOOST_PROGRAM_OPTIONS_DECL. You can 
> still use BOOST_PROGRAM_OPTIONS_DECL to export/import select methods 
> of that type, if needed.
>
> PS: I remember someone saying that on recent Windows 
> dllexport/dllimport attributes are no longer necessary. I don't quite 
> know how that works, but for backward compatibility we should probably 
> keep using BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT as described above.

I thought that BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT are exactly 
for this: You define *_DECL to *_EXPORT when building the library and 
*_IMPORT otherwise (and <empty> for static linking)

Why do individual libraries now have to deal with the Windows vs 
non-Windows case? Is there ANY Boost library which does this?

 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.

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.