Boost build fails C++11 feature checks when using (custom) GCC 4.x or 5.x
Asked Answered
D

2

8

I need to build Boost 1.62 and 1.63 on a Fedora 24 machine, but using GCC 4.9.3 or GCC 5.4.0 (depending on the version CUDA, which is the reason why I need an older compiler). But if I set the custom GCC version as described in this answer and run

/b2 --toolset=gcc-5.4.0 stage

To my chagrin, I now see:

    - 32-bit                   : no
    - 64-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes
    - symlinks supported       : yes
    - C++11 mutex              : no
    - lockfree boost::atomic_flag : yes
    - Boost.Config Feature Check: cxx11_auto_declarations : no
    - Boost.Config Feature Check: cxx11_constexpr : no
    - Boost.Config Feature Check: cxx11_defaulted_functions : no
    - Boost.Config Feature Check: cxx11_final : yes
    - Boost.Config Feature Check: cxx11_hdr_tuple : no
    - Boost.Config Feature Check: cxx11_lambdas : no
    - Boost.Config Feature Check: cxx11_noexcept : no
    - Boost.Config Feature Check: cxx11_nullptr : no
    - Boost.Config Feature Check: cxx11_rvalue_references : no
    - Boost.Config Feature Check: cxx11_template_aliases : no
    - Boost.Config Feature Check: cxx11_thread_local : no
    - Boost.Config Feature Check: cxx11_variadic_templates : yes

i.e. a lot of C++11 features are supposedly missing, while they should not be. This does not occur when building it with the distribution's GCC version (6.2.1).

Why is this happening and what should I do to make the Boost build recognize my GCC 5.4.0 (or 4.9.3)'s capabilities?

Devastate answered 3/10, 2016 at 7:59 Comment(11)
@JanHudec: CUDA 7.5 only supports GCC versions up to 4.9.xDevastate
You'll probably need to pass --std=c++11 or --std=c++0x. Maybe something like this answer. gcc 6.2.1 probably uses --std=c++14 by default.Moxie
@jv_: This doesn't seem to work, unfortunately.Devastate
Same symptom here. Using MinGW (GCC 4.9.2) bundled with Qt 5.6.1 on Windows.Gravettian
@Gravettian and einpoklum. I know it's not the same case, but comparing g++ 6.2(std=c++14 by default) and clang++ 3.8(std=c++98/03 by default). b2 toolset=gcc stage -> everything yes. b2 toolset=clang stage ->mostly no a couple of yes. After removing directory bin.v2 (to avoid the cached results), b2 toolset=clang cxxflags="--std=c++11" stage -> everything yes (except thread_local).Moxie
@jv_: Which directory did you remove exactly?Devastate
Every time you build boost intermediate files are put in BOOST_ROOT/bin.v2. That is the directory I deleted.Moxie
@llonesmiz: Make this an answer please, I think this worked.Devastate
@einpoklum: I deleted that bin.v2 and it still didn't work. I'm cross compiling using the NDK clang toolchain for ARM.I pass -std=c++14 in my jam file but this doesn't change behavior.Rafaello
@void.pointer: Hmm. I did something which worked, but by now I've forgotten what it was! Drats.Devastate
@Moxie Thank you ! deleting bin.v2 directory, along with using the command ./b2 cxxflags="-std=c++14" worked for me!Badalona
D
9

The following solution was tested with Boost 1.62.0 + GCC 4.x, Boost 1.62.0 + GCC 5.x and Boost 1.65.1 + GCC 5.x. YMMV with other Boost versions but I see no reason why it shouldn't work.

Let's assume for the sake of this example that:

  • You want to build Boost with GCC 5.4
  • The g++ 5.4 binary is at /some/where/g++-5.4
  • You've downloaded the Boost sources and unpacked them into /path/to/sources/of/boost-1.62.0/
  • (Perhaps) you want to install Boost to /dest/path
  • You have N cores (so you want to parallelize the build N-ways)

Now:

  1. (Optional: Make sure you have the libraries Boost likes to have, e.g.: zlib, bzip2, lzma, zstd, iconv, icu)
  2. cd /path/to/sources/of/boost-1.62.0/
  3. Booststrap the build system by running ./bootstrap.sh
  4. echo "using gcc : 5.4 : /the/path/to/g++-5.4 : <cxxflags>-std=c++11 ;" > ./tools/build/src/user-config.jam
  5. ./b2 --toolset=gcc-5.4 -j N (N being the number of cores on your system)
  6. ./b2 install --prefix=/dest/path

Notes:

  • The order of actions 2 and 3 doesn't matter.
  • Rejoice! This doesn't happen with GCC 6.x or later versions.
  • You can replace c++11 with c++1y if you want GCC 5.4.0's (non-finalized) C++14 support. If you're using a different GCC version, remember that before a standard is finalized you don't actually get its switch available. Thus C++11 used to mean --std=c++1x and C++17 was --std=c++1z and the switches change as GCC versions get released after standard finalization.
Devastate answered 1/5, 2017 at 8:37 Comment(0)
C
7

I'm having the same issue.

It seems that, because you are cross-compiling, the boost building system is trying to check if your compiler supports all of those c++11 features. The thing is, in order to do that, the build system compiles a sheet of code. One of those files is this: boost_1_62_0/libs/rational/test/constexpr_test.cpp

Then, the build system does what no one would think when using a cross-compiler... it tries to execute the resultant binary on the host computer... It obviously fails. That is happening for all of those cxx11_ tests. I'm also having that issue and it is a problem. Because of this, I'm unable to build Boost.Fiber for my Raspberries with OpenWRT.

Carpophagous answered 10/10, 2016 at 11:35 Comment(9)
While this explains the failure and gets you a +1, it doesn't help me overcome the problem :-(Devastate
Sorry. I did not noticed you had answered.Carpophagous
I hit return too soon... To be honest, In order to solve the issue from my side, I patched the Boost.Fiber build jamfile and removed all of the requirements. The boost devs never answered me and it was the only way for me to overcome the issue. Because of this issue, was not being able to build Boost.Fiber, because the building system simply refused to do that. You can see here, the patch that I submitted to OpenWRT github.com/openwrt/packages/pull/3510Carpophagous
@Claymore did you ever find a solution here? I see your comments on github about the problem, but I am not sure if v1.63 of boost has the solution. I'm cross compiling using NDK r14b for ARM using Clang + libc++. All the c++11 tests show "no" for support. Any help I can get?Rafaello
@Rafaello For OpenWRT, I have created a patch that removes the verifications from the Fiber Jamfile.v2 file. You can see it here It may work for you.Carpophagous
@Claymore: I've posted the answer, FYI.Devastate
@Devastate Did you tested it with cross-compilers for different archs? For example, for me, it is important to build Boost for OpenWRT and Boost is kinda picky with cross-compilers for different archs. The idea of trying to build and execute a binary to check for compiler capabilities, seems kinda silly to me, but that's how Boost currently works for dependency checks.Carpophagous
@Claymore: No, but - (1) The question wasn't about that and (2) Cross-compiling boost may involve other things than setting the --std flag and compiler path.Devastate
@Devastate Well, that is Ok. 1+ for you.Carpophagous

© 2022 - 2024 — McMap. All rights reserved.