Subject: Re: [Boost-build] zlib and bipz2 not linking?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-09-10 18:13:20
On 09/10/2018 11:47 AM, Kuhl, Brian wrote:
> Does this mean that the usage requirement are not being met, and therefore zlib is not being included?
I don't understand what you mean by "usage requirements are
not being met."
> The reason I ask is this line in the debug output ..
> Building target '/zlib'
> Build request: object(property-set)@2707 ...
> Command line free features: <testing.launcher>../../../status/vxworks_boost_test_run.exp
> Target requirements:
> Common properties: ...
> Usage requirements for zlib:
> Build properties: ...
> - zlib : yes (cached)
> Usage requirements from zlib: <relevant>cross-compile <relevant>link <relevant>static-only
> I find it odd that the "usage requirements from zlib:" include the two custom parameters I define in project-config.jam ?
> What does 'from' indicate in this context? A requirement that is new in some way? A requirement that is not matched?
These properties are returned after processing
the zlib target and are applied to all targets
that depend on zlib. <relevant> indicates that the
properties that you defined should be included
in the target paths.
>> -----Original Message-----
>> From: Steven Watanabe [mailto:watanabesj_at_[hidden]]
>> Sent: Friday, September 07, 2018 5:20 PM
>> To: Kuhl, Brian; Boost.Build developer's and user's list
>> Cc: Krejsa, Dan
>> Subject: Re: [Boost-build] zlib and bipz2 not linking?
>> On 09/07/2018 02:55 PM, Kuhl, Brian wrote:
>>> So I have several '<library>object(file-target)@' but I don't think they are for
>> /zlib and /bzip2? There are 6 '<library>object' and 6 dependent Boost libraries
>> on the link line.
>>> If zlib and bzip2 were being passed I think I should see 8, do you agree?
>> No. Boost.Test and Boost.IOStreams are direct dependencies
>> and are not included in the usage-requirements. You'll see
>> them listed somewhere nearby as sources. zlib and bzip2
>> appear to be present as the two searched-lib targets.
>> The problem is happening somewhere later on, but I'm
>> not quite sure where.
>> Oh. Are you using a modified version of Boost.Build?
>> In particular, if gcc.jam names the rule gcc.vxworks.link like you
>> tried in the thread "Is it possible to override CONFIG_COMMAND"
>> instead of gcc.link.vxworks, as I suggested, it will definitely
>> cause this problem among others.
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