Reason is that Win32 needs the declspec on classes: https://docs.microsoft.com/de-de/cpp/cpp/using-dllimport-and-dllexport-in-cp... You only need dllimport for variables. If you don't apply it to types, MSVC "does the right thing". Then why do the MSVC docs say otherwise? Or what am I missing from the
Am 02.02.21 um 13:44 schrieb Niall Douglas via Boost: posted link?
Could you elaborate why marking classes currently marked as BOOST_*_DECL with BOOST_SYMBOL_VISIBLE would make visibility not have an effect? BOOST_SYMBOL_IMPORT You would export an imported library's exported symbols in your own library's exported symbols set.
If you want that, choose -fvisibility=default, because if you do as you suggest, it's the same thing. People asking for -fvisibility=hidden specifically are requesting you don't export unrelated symbols from your library's symbol export set. You can go ahead and do it anyway, but users would rightly complain that Boost is messing up their links. If you consider that some use a visibility hidden internal Boost to prevent collision with end users using their own Boost, I can foresee a bunch of angry users.
The exception in question is marked with BOOST_*_DECL which is empty for consumers and hence hidden visibility if the consumer builds with hidden visibility. That is a bug in ProgramOptions. I'm either misunderstanding you are this is contradiction what you wrote above. If the current behavior of expanding BOOST_*_DECL to either BOOST_SYMBOL_EXPORT or BOOST_SYMBOL_IMPORT when DYN_LINK is defined is wrong, and using BOOST_SYMBOL_VISIBLE is wrong and not using anything does not work per the GCC docs and experience on OSX, then what is the correct way?