On 7/6/2010 7:11 PM, Robert Ramey wrote:
Let me expand a little bit on the issue of code-stripping which cost me a huge amount of hassle to find a way around.
a) build and test seriialization library in debug mode. b) everything works great c) build and test in release mode - uh oh - tests using exported pointers fail. But only with MSVC. d) After some investigation, it's determined that code not explicitly referred to is being stripped. e) After lot's of experimentation, it's found we can mark the functions as dll_export to be sure they are not dropped. These are not functions in the library, but rather templates instantiated inside the user's code. MSVC uses this to implement Automation where one application can use COM to call into one application from another. f) This workaround was "codified" in boost/serialization/force_include.hpp" g) This problem never arose with gcc. I'm not sure whether this is because gcc doesn't do any code stripping or what.
By default, GCC exposes all symbols, so it wouldn't have stripped anything.
Now I'm wondering if one builds with gcc in release mode with visibility=hidden, if we'll get a whole rash of test failures.
It is certainly possible as there may well be things that must be marked visible that don't need to be exported for MSVC. That is, you've identified everything that must be exported to make MSVC happy, but there may yet be other things to mark visible when using GCC's -fvisibility=hidden. Note that GCC's visibility applies to class templates, too, because static data members of class templates must be marked visible to avoid multiple definitions in shared objects and referenced separately (violating the ODR, of course).
I'm not sure I really have a point here. It just seems that this is going to take more time than one would expect to play itself out.
Perhaps, but it shouldn't be too significant. There may be some help in comparing the exports from the DLL with the strong symbols visible in the DSO. Finally, I should have mentioned, in case you weren't aware of it, that BOOST_SYMBOL_VISIBLE is available for marking things visible that needn't (or shouldn't) be marked with __declspec(dllexport). ___ Rob