[Serialization] extra_detail namespace breaks ability to multiply export classes

I've been using serialization in a client-server application where the client and server support different archive types, and the same "message" classes need to be exported for a different set of archives in the client and server cases. For example: *Client*: links to libNetwork. libNetwork supports export of Message class by, e.g. Message.hpp: struct Message { }; BOOST_CLASS_EXPORT_KEY(Message) network.cpp: #include <network_oarchive.hpp> #include <network_iarchive.hpp> #include <Message.hpp> BOOST_CLASS_EXPORT_IMPLEMENT(Message) template void Message::serialize<network_oarchive>(.......); template void Message::serialize<network_iarchive>(.......); On the server, I also need serialization support for Message over a new archive type which only the server knows about: *Server*: links to libNetwork AND libServer. libServer supports export of Message class by, e.g. server.cpp: #include <server_oarchive.hpp> #include <server_iarchive.hpp> #include <Message.hpp> BOOST_CLASS_EXPORT_IMPLEMENT(Message) template void Message::serialize<server_oarchive>(.......); template void Message::serialize<server_iarchive>(.......); For boost 1.43 and earlier, this was all fine; the client had sufficient serialization code for its archives and so did the server. With 1.45, boost/export.hpp dropped the anonymous namespace used for GUID instatiation so now the boost::archive::detail::extra_detail::init_guid<Message>::g symbol is multiply defined (first in libNetwork, then in libServer) and I can't link. If drop the BOOST_CLASS_EXPORT_IMPLEMENT from libServer, I get unregistered class exceptions on the server, because the guid_initializer in libNetwork never "knew" about my server_oarchive. What was wrong with the anonymous namespace usage? Any help appreciated, Simon
participants (1)
-
Number Cruncher