Rob Stewart wrote:
On 7/6/2010 7:11 PM, Robert Ramey wrote:
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).
lol - yet another facet. The serialization library instantiates static variables for each exported type. Depending on how the user distributes his code among DLLS and main module there can be multiple instances of this. Currently this is being trapped by the library as a possible violation of ODR with no real guarenteed that the code in the different DLLS have the same same implemenation version. For now I've just commented out the assertion which traps this, but seems like an accident waiting to happen so in the future I expect to re-enable the trap and and permit users to override it. I believe this behavior has occurred on both MSVC and gcc - but I could be wrong.
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).
All this really caught me by surprise. Is there any documentation on this? Is there a comprehensive set of tests to verify how this works in different compilers? Seems to me there are a number of interrelated facets. a) visibility b) code stripping c) handling of the same instantiated code in different modules d) interaction with auto-linking (through shared macro names) e) at least 3 different compilers which have at least slight differences (MSVC, gcc, Borland, and ?) f) at least as far as I know - no guidence from the C++ standard. g) our testing regimen doesn't really test all combinations - debug/release dll/lib, auto-lib/no-autolib, in a comprehensive and systematic way. So we can't know when we've really got it right. I've had to spend a lot of time on all of the above. It was in an ad hoc / piecemeal fashion which was not at all satisfactory. So sorting all this out is a very worthwhile task. But I can't help thinking that the scope of this issue and size of the task has been underestimated. Robert Ramey