On 7/6/2010 2:58 PM, Robert Ramey wrote:
John Maddock wrote:
autolink code is being enabled by BOOST_HAS_DECL which is now now being used to enable "visibility". This is likely even more confused as I believe I've used this or something like it to trick the compiler/linker into suppressing code stripping of code not otherwise explicitly referred to.
GCC's visibility feature is actually very similar to msvc's import/export feature - just a different name. Using it to prevent code being stripped will continue as before for msvc, and probably have no effect (as before) for gcc.
GCC's visibility varies from MSVC's dllexport/import in subtle ways, but is largely the same in effect, but only with -fvisibility=hidden.
Hmmm - now I'm wondering about code stripping in gcc. Why is this not a problem for this compiler? Does it never strip code? Does it depend on compile time switches that we don't user or ???.
Without that switch, GCC exposes all symbols. That would be the same as if declspec(dllexport) were applied to every symbol when using MSVC.
To my mind, the problem is that the library depends on behavior outside the scope of the C++ standard so we sort of end up addressing these issues by trial and error. It seems the whole subject of runtime linking is basically undefined.
It is undefined WRT the C++ Standard, but it is well defined for MSVC and GCC. The issue is one of understanding the behavior of those two platforms, not trial and error. To further clarify GCC's visibility, note that once -fvisibility=hidden is used, GCC will expose no symbols by default. That's equivalent to MSVC's default behavior, which is why declspec(dllexport)/import is needed with MSVC. However, just changing the dllexport/import macros to make things visible for GCC isn't sufficient. There are some symbols that MSVC automagically exports that GCC does not. That means there are some symbols that must be marked visible for GCC that needn't been exported for MSVC, such as exception classes and types that are used in dynamic_casts. Whether those are an issue for Boost.Serialization, I couldn't say. HTH, Rob