Re: [Boost-users] [serialization] 1.35 problem with explicitinstantiation

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