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.

Regards,

Kevin

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

AMDG

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.
You might check that BOOST_PROGRAM_OPTIONS_DYN_LINK
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