|
Boost-Build : |
Subject: Re: [Boost-build] Static library using shared one
From: Paul Graphov (graphov_at_[hidden])
Date: 2013-03-06 05:55:05
Thank you for answering.
But this solution won't work well if I use link=static from command
line, which is frequently used for local builds to avoid installing
needed boost version system wide. Is there any way to say that library
should be linked "default" way, i.e. stop this requirement from
propagating?
Also bjam seems to rejects this entirely:
....
lib my_lib
:
lib.cxx
:
<use>/boost//system <link>shared
<link>static
;
....
# bjam -d
explicitly-specified values of non-free feature <link> conflict
Thanks.
On Wed, Mar 6, 2013 at 2:43 PM, Juraj IvanÄiÄ <juraj.ivancic_at_[hidden]> wrote:
> On 6.3.2013. 10:26, Paul Graphov wrote:
>
>> I was unable to find an answer in the documentation so I decided to ask
>> here.
>> I'm working on a project that uses boost-build. Build process has two
>> results: main binary file and regression test that is run
>> automatically by boost-build. Both share a lot of common object files.
>> To avoid copy-paste in Jamroot and complaints about targets with the
>> same name I separated that common files into a static library (let it
>> be my_lib). The problem is that some code in that library depends on
>> boost.system which I want to be shared (unless I use link=static at
>> command line). If I just mention my_lib and /boost//system in sources
>> of both binaries they may be passed to the linker in wrong order. But
>> if I also mention /boost//system in either sources or via <use> in
>> requirements for my_lib, it seems to try compiling it both static and
>> shared and fails with error:
>
>
> The problem is that <link>static in in my_lib is propagated to the
> /boost//system target.
>
> Simplest fix is to force shared link on it - i.e.
>
> <use>/boost//system/<link>shared
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk