Dan Thill wrote:
I think the problem is that you are using a static library which contains the serialization code. Static libraries are notorious for not linking code that is never directly called. So the solution is to include the object files contained in your static library into your executable/dll. For Visual C++, there is no command line linker option as I understand it. On gcc, you can do g++ -Wl,--whole-archive if memory serves (which I'm sure it doesn't)
I'm beginning to see that this is the case. However, there are several references on this list over the years for this exact organization. It worked on 1.34.1 -- I suppose because BOOST_CLASS_EXPORT had to be called in the header file. However, with 1.35, the new system which avoids the header ordering issue, which requires BOOST_CLASS_EXPORT to be in the implementation file, breaks this approach. I thought that was one of the benefits of the new system: to better force instantiation of the static objects which make the registration work.
Yes, but if your linker throws away the code, then there is no point.
And, according to the trunk version, putting serialization code in DLLs is supposed to work--using the same organization I'm trying to use now. But it looks like it won't work with static libs.
This is a misfeature of static libraries, not anything else. For example, if you want to have a function thats called when your library is loaded into memory, gcc provides an attribute that looks something like: void call_me_please() __attribute__((constructor)) {...} But if you put that function in a static library, it never gets looked at because it is never referenced. So you *have* to link the object containing call_me_please into the final executable/dll. The same is true for the serialization code, as it works similarly to the above.
I'm sorry if I sound irate. I'm just extremely frustrated. I went through all the effort to put the 1.34.1 serialization into its own library in order to fix compilation time problems in our product. And then, a few days later, 1.35 is released, breaking everything. (and for various platform issues, we need to move to 1.35).
Do you mean compile-time or link-time? Anyway, I think the only reason 1.34 worked for you is because you had BOOST_CLASS_EXPORT in the header files. Otherwise I would have expected the same thing to happen. If you really want a separate library, I think you have to include all the object files in your final link. This helps compile-times, but not link-times. Maybe the incremental linker will work for you. Good luck. -- Sohail Somani http://uint32t.blogspot.com