Boost install can fail due to user-config.jam

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
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.