building bjam with custom CFLAGS fails if $CFLAGS contains extra white space

[Sebastian Mingramm <s.mingramm@…>]

Steps to reproduce:

cd boost_1_41_1_beta1/tools/jam/src/
export CFLAGS="-O2 -pipe"
export CC="x86_64-pc-linux-gnu-gcc"
./build.sh cc

Output:
[...]
[COMPILE] bin.linuxx86_64/bjam
x86_64-pc-linux-gnu-gcc: : No such file or directory
expand.c: In function 'var_expand':
expand.c:85: warning: field precision should have type 'int', but argument 2 has type 'long int'
variable.c: In function 'var_string_to_file':
variable.c:408: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
variable.c:409: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result

"x86_64-pc-linux-gnu-gcc" -o bin.linuxx86_64/bjam "-DNDEBUG" "-DOPT_HEADER_CACHE_EXT" "-DOPT_GRAPH_DEBUG_EXT" "-DOPT_SEMAPHORE" "-DOPT_AT_FILES" "-DOPT_DEBUG_PROFILE" "-DOPT_FIX_TARGET_VARIABLES_EXT" "-DOPT_IMPROVED_PATIENCE_EXT" "-DYYSTACKSIZE=5000" "-O2" "" "-pipe" "-s" "-O" "command.c" "compile.c" "debug.c" "expand.c" "glob.c" "hash.c" "hcache.c" "headers.c" "hdrmacro.c" "jam.c" "jambase.c" "jamgram.c" "lists.c" "make.c" "make1.c" "mem.c" "newstr.c" "option.c" "output.c" "parse.c" "regexp.c" "rules.c" "scan.c" "search.c" "subst.c" "w32_getreg.c" "timestamp.c" "variable.c" "modules.c" "strings.c" "filesys.c" "builtins.c" "pwd.c" "class.c" "native.c" "modules/set.c" "modules/path.c" "modules/regex.c" "modules/property-set.c" "modules/sequence.c" "modules/order.c" "execunix.c" "fileunix.c" "pathunix.c"

...failed [COMPILE] bin.linuxx86_64/bjam...
...failed updating 1 target...

What happens is that the extra white space gets converted into a "", which gcc doesn't like. There are bug reports on the gentoo bugzilla for boost 1.35 [1], 1.39, 1.40 and it's present in 1.41.0_beta1. It was also reported that the problem occurs with LDFLAGS [1, comment 27].

[1] ​https://bugs.gentoo.org/show_bug.cgi?id=265402

[ohnobinki@…]

fixes compilation for >=boost-build-0.39 for me

[René Rivera]

I can't seem to reproduce the problem on the latest bjam 3.1.18. Although I don't have access to a Gentoo system, so I'm only trying it on a MacOSX bash. I don't see the extra "" in CFLAGS when I force the cc toolset.

[Sebastian Mingramm <s.mingramm@…>]

The problem is still there. For some reason the CFLAGS in my steps to reproduce don't contain extra white spaces. You need something like:

export CFLAGS="-O2 -pipe "

This happens with the bjam shipped with boost 1.42 on linux with bash 4.0.35 (older bash versions were affected too).

[René Rivera]

(In [60768]) Fix possible problems when trailing or leading whitespace is added to the env vars used, for example CC and CFLAGS when using the cc toolset. Even though I can't get compilation to fail even with the extra whitespace during building it does seem to fail for some compilers that don't ignore the whitespace arguments. (Fixes #3630)

[Sebastian Mingramm <s.mingramm@…>]

The patch works, thank you. Could you please add LDFLAGS to list of checked variables? It's affected too.

[Sebastian Mingramm <s.mingramm@…>]

Oh, I missed that we inject the user's LDFLAGS through the LIBS variable. That means LIBS needs to be in this list. Thank you.

[ohnobinki@…]

I think that LIBS still needs to be fixed(?)

[René Rivera]

Turns out this was ​fixed long ago.