Boost logo

Boost :

From: Glenn Schrader (gschrad_at_[hidden])
Date: 2007-01-08 12:41:47


The attached patch file fixes a problem that I have been having
attempting to build a recent version from cvs with gcc 4.1.1
on sparc solaris 2.8. Just to make sure I wasn't seeing things
I also tried a build on Linux (FC5, gcc 4.0.1) and got the
same results.

running configure then make was produceing output that
included the following lines:

...updating 695 targets...
MkDir1 bin.v2
MkDir1 bin.v2/libs
MkDir1 bin.v2/libs/program_options
MkDir1 bin.v2/libs/program_options/build
MkDir1 bin.v2/libs/program_options/build/gcc-4.1.1
Copyright
MkDir1 bin.v2/libs/program_options/build/gcc-4.1.1
Copyright/release
ETC...

Note the additional newlines and the word 'Copyright'.
This should have been:

...updating 695 targets...
MkDir1 bin.v2
MkDir1 bin.v2/libs
MkDir1 bin.v2/libs/program_options
MkDir1 bin.v2/libs/program_options/build
MkDir1 bin.v2/libs/program_options/build/gcc-4.1.1
MkDir1 bin.v2/libs/program_options/build/gcc-4.1.1/release
ETC...

The fragment of the paths after build/ is determined
by bjam based on parsing the output of 'gcc --version'.
My compiler produces:

$> gcc --version
gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$>

Jam appears to build a single string out of this output, newlines
and all. The real problem is in tools/build/v2/tools/gcc.jam.
The line that parses the gcc output is:

local command-info = [ MATCH "^[^ ]+[ ]+[^ ]+[ ]+([^ ]+)[^(]*[(]?([^)]*)"

The regex snippet that should match the version number is '([^ ]+)'.
The problem is that since '\n' != ' ' everything from 4.1.1 through
Copyright is being matched and being interpreted as part of the
compiler version. This agrees with the bad output above. I also
checked for 'bin.v2/libs/program_options/build/gcc*' and ls indeed
shows a filename with an embedded newline (this makes the ls output
look pretty strange).

The attached patch modifies tools/jam/src/regexp.c to add support for
using newlines in character ranges and changes the above line in
gcc.jam to:

local command-info = [ MATCH "^[^ ]+[ ]+[^ ]+[ ]+([^ \\n]+)[^(]*[(]?([^)]*)"

Has anybody else seen this?

-glenn

diff -ru boost-20070103/tools/build/v2/tools/gcc.jam boost-20070103-new/tools/build/v2/tools/gcc.jam
--- boost-20070103/tools/build/v2/tools/gcc.jam 2006-12-24 16:27:14.000000000 -0500
+++ boost-20070103-new/tools/build/v2/tools/gcc.jam 2007-01-08 11:27:09.591881456 -0500
@@ -78,7 +78,7 @@
         # The 'command' variable can have multiple-element. When calling
         # the SHELL builtin we need a single string.
         local command-string = $(command:J=" ") ;
- local command-info = [ MATCH "^[^ ]+[ ]+[^ ]+[ ]+([^ ]+)[^(]*[(]?([^)]*)"
+ local command-info = [ MATCH "^[^ ]+[ ]+[^ ]+[ ]+([^ \\n]+)[^(]*[(]?([^)]*)"
             : [ SHELL "$(command-string) --version" ] ] ;
         version ?= $(command-info[1]) ;
         switch $(command-info[2]:L)
diff -ru boost-20070103/tools/jam/src/regexp.c boost-20070103-new/tools/jam/src/regexp.c
--- boost-20070103/tools/jam/src/regexp.c 2006-09-06 22:57:02.000000000 -0400
+++ boost-20070103-new/tools/jam/src/regexp.c 2007-01-08 11:26:31.469584407 -0500
@@ -518,6 +518,14 @@
                                                         regc(classr);
                                                 regparse++;
                                         }
+ } else if (*regparse == '\\' ) {
+ regparse++;
+ if (*regparse) {
+ char ch=*regparse++;
+ if (ch == 'n') { regc('\n'); }
+ else { regc('\\'); regc(ch); }
+ } else
+ regc('\\');
                                 } else
                                         regc(*regparse++);
                         }


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk