John Maddock wrote:
My guess as to what's happening here is that one source file is seeing symbol X with a __declspec(dllexport) attribute because BOOST_SERIALIZATION_SOURCE is defined for that source, where as another source file is seeing the same symbol without the __declspec() attribute because BOOST_SERIALIZATION_SOURCE is not defined for it. The result is that the two source files end up looking for different mangled names for that symbol and hence the error. The most consistent way to deal with this is to set BOOST_SERIALIZATION_SOURCE for all source the files.
Hmmm - I don't think that works. In part because of the way code is structured. The serialization library is packaged as two DLL/libs: serialization.dll and wserialization.dll This was done so that those who don't use wide characters don't have to carry around any useless code. But wserialization depends upon code included in serialization.dll. So when a module from wserialization compiles, functions defined in wserialization need to be exported while functions defined in serialization.dll need to be imported. So I've had the policy of onl including BOOST_SERIALIZATION_SOURCE in those modules which implement functions to be exported. I think that is the correct policy. Actually the situation is slightly more complicated, but you get the idea. I'm thinking that the situation has been made somewhat confusing by the fact that autolinking headers includes macros to make exported functions visible for MSVC as well as Borland. It's likely that there's some sort of conflict or interaction with the new "visibility" setup. I haven't had an opportunity to really look into this yet so feel free to take these observations with a grain of salt. Robert Ramey
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost