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 04:23:59

Anthony,

I applied some modifications to the project you sent to compile it on my system (WinXP, msvc 8 - I don't currently have a unix system at hand), and managed to reproduce the behavior you described. Please see my results inline.

I wrote:
> 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.

No difference. It tries to build utilities.dll even though lib utilities has <link>static in its requirements. Weird.

> > 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.

Scratch that, it won't work as none of the alternatives would be a match. Bjam gives "No best alternative" error. Sorry for misleading suggestion.

> > 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.

It's getting partially overridden - utilities.dll gets created but then the test executable is tried to link with libutilities.lib and fails, naturally. I also think giving an explicit error about conflicting requirements would be better. I'll try to prepare a minimal test case for this issue and post it in a new thread.

> > 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.

That didn't work.

But I have another suggestion which I somehow managed to forget but it worked for me in a similar situation in the past :-)
Here it is:

alias lib-real-time
   : [ lib rt ]
   : <threading>single
   ;

alias lib-real-time ;

Hope this one will work, at last.

> > -- Anthony Foglia
> 
> 
> Thanks,
> Gevorg

HTH,
Gevorg