Subject: Re: [Boost-build] zlib and bipz2 not linking?
From: Kuhl, Brian (brian.kuhl_at_[hidden])
Date: 2018-09-12 21:07:31
I backed out the link-with-ld generators and the libraries being added to the link line now. However if I add
project : requirements <static-only>on:<link>static
b2 link=static ...
The libraries are mangled
Any ideas how I can correct this?
> -----Original Message-----
> 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:
> > Target requirements:
> > Common properties: ...
> > Usage requirements for zlib:
> > Build properties: ...
> > - zlib : yes (cached)
> > Usage requirements from zlib: <relevant>cross-compile <relevant>link
> > 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-----
> >> 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
> >> 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>
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