From: Sohail Somani (sohail_at_[hidden])
Date: 2008-04-13 18:32:24
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