Re: [Boost-build] Linking static library against shared library

Subject: Re: [Boost-build] Linking static library against shared library
From: Gevorg Voskanyan (v_gevorg_at_[hidden])
Date: 2010-05-15 01:19:19

Anthony,

This made more sense to me after getting a sleep :)

Anthony Foglia wrote:
> But, I've also put <link>static in the requirements 
> for utilities.  Why should the usage requirements of a source _override_ 
> the requirements of the dependent target?  I could understand if I get an 
> error saying they conflicted, and a failure to build.  At least then you'd 
> find the error earlier.  But that doesn't happen.  What are 
> "requirements" if not required?

Honestly, this is surprising to me as well. I'll try the tarball you sent in my environment, which has newer versions of Boost.Jam (03.1.18) and Boost.Build, both from Boost 1.43.0.

> Gevorg Voskanyan wrote:
>> Just move it to the requirements 
>> section like this:
>> 
>> lib lib-real-time        
>>     #FOR: librt (implicit for threading)
>>  
>> :
>>   : <threading>single <name>rt 
>> <link>shared
>>   ;

> I had tried that, and that doesn't 
> work either.  In that case, librt doesn't appear in the linker command at 
> all, and I get undefined references.  Here's the linker command for a test 
> program I made:

[snip commands]

> I need a "-lrt" after the -Wl,-Bdynamic to get it to compile.

[snip commands]

Sorry, I had forgotten you had two alternatives for lib-real-time :)
That means "alias lib-real-time : : ;" is selected for lib utilities as the latter has requirement <link>static and the other lib-real-time alternative has requirement <link>shared causing that alternative not to be a match, even if that one is better for the <threading> alone. That easily explains the undefined references. To avoid that, you can put <link>shared as a requirement for the other alternative too:

alias lib-real-time : : <link>shared ;

I was thinking of the definition of lib-real-time I proposed, which should make the alias unnecessary, and forgot that alias actually existed :) Again sorry about that.

> If I put <link>shared in the usage 
> requirements of lib-real-time, I get:

[snip]

> It's trying to 
> build a shared library, by linking statically to the sources.

Hmm, yes, this is the case we talked about above. lib utilities' <link>static requirement seems to get overriden by lib-real-time's <link>shared usage requirement. I'll check to see if it's the case in newer version too, and if so, probably start a new thread about this specific issue.

> I've 
> pared the code down to a handful of files.  I'll ask for permission to send 
> a tarball to the list.

Yes, I've seen them attached in your more recent mail. I'll take a look at it today.

>> Also I think you can get away with just one 
>> alternative of lib-real-time if it is defined as
>> 
>> lib-real-time
>>   :
>>   : <link>shared 
>> <threading>single:<name>rt
>>   ;
>> 
>> and 
>> then "alias lib-real-time : : ;" would no longer be 
>> needed.

> Probably.  But it also might end up trying to link to a 
> library named lib-real-time in multithreaded builds.  The documentation is 
> not clear.  Those lines were written a while ago and have been working, and 
> I'm not eager to go looking for trouble trying to change them.

OK, I'll check if that works or not too.

> -- Anthony Foglia

Thanks,
Gevorg