The boost build in the stack can fail if the user has a custom user-config.jam file in their home directory with incompatible settings. A workaround is to temporarily rename user-config.jam to something else.
I’m not all that sympathetic. If a user is confident enough about bjam to install their own local jam file then caveat emptor. KTL proposes that we generate a warning if a user jam file is detected, and that’s an option, but if I had my own cunningly crafted configuration I’d find the continual warnings annoying.
In my case, i was attempting to learn how to use Boost Python - hence the (probably) badly configured user-config.jam file. Perhaps the best solution is to just have the fix documented here so that it is easy to tell if this is the reason for the build failure.
A telltale signs that a custom user-config.jam file is responsible for causing the boost build to fail - Look at the build log. I noticed that b2 attempted to build object files with “c++” missing at the front of the build command i,e. it wasn’t actually invoking any compiler. Eg.
gcc.compile.c++ bin.v2/libs/thread/build/gcc/release/threading-multi/future.o
-ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic
-pthread -fPIC -Wextra -Wno-long-long -Wno-unused-parameter
-Wno-variadic-macros -Wunused-function -pedantic -std=c++11
-DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1
-DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO
-DBOOST_THREAD_POSIX -DNDEBUG -I"." -c -o
"bin.v2/libs/thread/build/gcc/release/threading-multi/future.o"
"libs/thread/src/future.cpp"
This results in the following error message
/bin/sh: 2: -ftemplate-depth-128: not found
i.e. the system assumes that -ftemplate-depth-128 (a compiler option) is a script and then complains that it cannot find said script. This may be a reasonable indication that a bad user-config.jam file is to blame.