Robert Ramey wrote: I woke up last night and remembered how I dealt with this in one of the examples. Suppose you've compiled everything into a static library X. There is a header b.hpp which looks like: class derived : public base { ... template<class Archive> void serialize(Archive & ar, const unsigned int version); }; and X will contain a b.cpp file which looks like #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_oarchive.hpp> ... // other archives template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar & ... } // explicit instantiation template void derived::serialize(boost::archive::text_oarchive & ar, const unsigned int version); template void derived::serialize(boost::archive::text_iarchive & ar, const unsigned int version); ... Now we have program A linked to library X. If A only serializes through a pointer to the class "base" then the code in b.cpp isn't linked in. The easiest way to handle this is to NOT put b.cpp into library X but rather link it in explicitly into program A. So the make for program A looks like A.exe : A.obj b.obj X.lib In effect, the link specification becomes the equivalent "export registration". The only way this will break down is if the linker is too smart for our own good. If you want a finer granularity, you can slightly reorganize code so that you have b_text.cpp, b_binary, etc Or use a compile time switch to indicate which archives you want generated like c++ b.cpp -DARCHIVE=text_iarchive ... or just use the polymorphic archive for everything there are tested demos for doing this. To summarize, I believe that explicitly including modules with instantiating code will be the equivalent to "export registration" since these modules include the static singletons whose pre-main construction makes the required types accessible to the system. I think this is the best way to handle this. In fact, I think this is soo good it should be added as a "case study" to the serialization library documentation. Robert Ramey