Re: zlib and bipz2 not linking?

AMDG

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.

> Brian
> 
>> -----Original Message-----
>> From: Steven Watanabe [mailto:[email protected]]
>> 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?
>>
>> AMDG
>>
>> 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.
>>
>>> <snip>
>>>
>>> <snip>
> 
> 

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build