Modify

Opened 8 years ago

Closed 3 years ago

#3630 closed Bugs (fixed)

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

Reported by: Sebastian Mingramm <s.mingramm@…> Owned by: René Rivera
Milestone: Boost.Jam 3.1.18 Component: build
Version: Boost.Jam 3.1.16 Severity: Problem
Keywords: Cc: ohnobinki@…

Description

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

Attachments (1)

boost-build-flags-unescape.patch (1.6 KB) - added by ohnobinki@… 8 years ago.
fixes compilation for >=boost-build-0.39 for me

Download all attachments as: .zip

Change History (13)

comment:1 Changed 8 years ago by ohnobinki@…

Cc: ohnobinki@… added

Changed 8 years ago by ohnobinki@…

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

comment:2 Changed 8 years ago by René Rivera

Component: Nonebjam
Milestone: Boost 1.41.0Boost.Jam 3.1.18
Owner: set to René Rivera
Version: Boost 1.40.0Boost.Jam 3.1.16

comment:3 Changed 8 years ago by Vladimir Prus

Component: bjambuild
Owner: changed from René Rivera to Vladimir Prus

comment:4 Changed 8 years ago by René Rivera

Component: buildbjam
Owner: changed from Vladimir Prus to René Rivera

comment:5 Changed 8 years ago by René Rivera

Resolution: worksforme
Status: newclosed

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.

comment:6 Changed 8 years ago by Sebastian Mingramm <s.mingramm@…>

Resolution: worksforme
Status: closedreopened

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

comment:7 Changed 8 years ago by René Rivera

Resolution: fixed
Status: reopenedclosed

(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)

comment:8 Changed 8 years ago by Sebastian Mingramm <s.mingramm@…>

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

comment:9 Changed 8 years ago by 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.

comment:10 Changed 7 years ago by ohnobinki@…

Resolution: fixed
Status: closedreopened

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

comment:11 Changed 7 years ago by René Rivera

Component: bjambuild

comment:12 Changed 3 years ago by René Rivera

Resolution: fixed
Status: reopenedclosed

Turns out this was fixed long ago.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain René Rivera.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.