Why is thread-for-install considering two identical options?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is thread-for-install considering two identical options?

Boost - Build mailing list

I’m not sure why I get this new error?

All I did was move a few of the parameters I invoke b2 with into a project-config.jam as requirements.

 

project : requirements

          <static-only>on:<link>static

          <static-only>on,<link>shared:<build>no

          <static-only>kernel:<link>static

          <static-only>kernel,<link>shared:<build>no

          <threadapi>pthread

          <binary-format>elf

          <abi>sysv

          <threading>multi

          <target-os>vxworks

 

 

.. error in configuration checks….

 

Performing configuration checks

    - default address-model    : 64-bit

    - default architecture     : x86

    - symlinks supported       : yes

    - C++11 mutex              : no

    - lockfree boost::atomic_flag : yes

    - has_icu builds           : no

    - zlib                     : yes

    - bzip2                    : yes

    - lzma                     : no

    - gcc visibility           : yes

    - long double support      : yes

    - BOOST_COMP_GNUC >= 4.3.0 : no

error: No best alternative for ./thread-for-install

    next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi

        matched

    next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi

        matched

error: No best alternative for ./thread-for-install

    next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi

        matched

    next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi

        matched

Component configuration:

    - atomic                   : building

    - chrono                   : building

    - container                : not building

    - context                  : building

    - contract                 : not building

    - coroutine                : building

    - date_time                : building

    - exception                : building

    - fiber                    : not building

    - filesystem               : building

    - graph                    : building

    - graph_parallel           : not building

    - iostreams                : building

    - locale                   : not building

    - log                      : not building

    - math                     : building

    - mpi                      : not building

    - program_options          : building

    - python                   : not building

    - random                   : building

    - regex                    : building

    - serialization            : building

    - signals                  : not building

    - stacktrace               : not building


_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Why is thread-for-install considering two identical options?

Boost - Build mailing list
AMDG

On 09/22/2018 09:16 PM, Kuhl, Brian via Boost-build wrote:

> I'm not sure why I get this new error?
> All I did was move a few of the parameters I invoke b2 with into a project-config.jam as requirements.
>
> project : requirements
> <snip>
>           <threading>multi
> <snip>
> error: No best alternative for ./thread-for-install
>     next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi
>         matched
>     next alternative: required properties: <abi>sysv <binary-format>elf <target-os>vxworks <threadapi>pthread <threading>multi
>         matched
>

This is a bug in the handling of target alternatives.
Only one of these should have <threading>multi... except
that it was inherited from your project-config.jam,
making them identical.  Workaround: put the non-conditional
requirements in the default-build, instead of the requirements.

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