Hi Steven,

Thank you very much. I didn't see that define in the response.rsp. I worked around the problem by adding the define to the b2 arguments. 

Should I file an issue for this, or is this expected behavior, going forward? It seems to me that 1 of 2 issues may be occurring:

1. bcp failed to copy the build, correctly, in this instance.
2. There is an issue with the boost-lib target assuming that staging should include export libs.

I can live with the workaround.


On Tue, Sep 4, 2018 at 1:57 PM Steven Watanabe via Boost-build <boost-build@lists.boost.org> wrote:

On 08/29/2018 01:43 PM, Kevin Maskell-Moody via Boost-build wrote:
> Our Boost build is a subset of all the modules. After upgrading to Boost
> 1.68.0, our build is now failing on the program_options target. It does
> appear to produce the program_option dll's, but not the export libs.

That usually indicates that no symbols are exported.
is defined when compiling.  (Look in the .rsp file)

> To be honest, I don't even know what target is including program_options,
> because we don't explicitly include program_options in the bcpCopy command.

I suspect that the dependency is from an example in
one one of the libraries you're using.

> I'm assuming filesystem by the looks of the following output.

The order is irrelevant, because Boost.Build
doesn't necessarily see the dependencies in the
same way that bcp does.

In Christ,
Steven Watanabe
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build