Re: [Boost-bugs] [Boost C++ Libraries] #7212: ./b2 fails with 'import error: length of source and target rule name lists don't match!'

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7212: ./b2 fails with 'import error: length of source and target rule name lists don't match!'
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-08-29 20:36:58

#7212: ./b2 fails with 'import error: length of source and target rule name lists
don't match!'
-------------------------------+--------------------------------------------
  Reporter:  anonymous         |       Owner:  vladimir_prus
      Type:  Bugs              |      Status:  new          
 Milestone:  To Be Determined  |   Component:  build        
   Version:  Boost 1.51.0      |    Severity:  Problem      
Resolution:                    |    Keywords:               
-------------------------------+--------------------------------------------

Comment (by anonymous):

 Hi!

 I have looked more into the problem and as far as I can see it is
 clearly related to compiler optimization.
 Below I have included all relevant information, so please accept my
 apologies for the lengthy comment.

 Target system information:
 {{{
 $ uname -a
 Linux munin-4 2.6.16.60-0.69.1_1.0102.5650.2.2.74-ss #1 SMP Tue Dec 21
 17:20:07 CST 2010 x86_64 x86_64 x86_64 GNU/Linux

 $ g++ -v
 Using built-in specs.
 COLLECT_GCC=/opt/gcc/4.6.0/bin/../snos/bin/g++
 COLLECT_LTO_WRAPPER=/opt/gcc/4.6.0/snos/libexec/gcc/x86_64-suse-
 linux/4.6.0/lto-wrapper
 Target: x86_64-suse-linux
 Configured with: ../xt-gcc-4.6.0/configure
 --prefix=/opt/gcc/4.6.0/snos --disable-nls
 --libdir=/opt/gcc/4.6.0/snos/lib --enable-languages=c,c++,fortran
 --with-gxx-include-dir=/opt/gcc/4.6.0/snos/include/g++
 --with-slibdir=/opt/gcc/4.6.0/snos/lib --with-system-zlib
 --enable-shared --enable-__cxa_atexit x86_64-suse-linux
 --with-mpc=/opt/gcc/mpc/0.8.1 --with-mpfr=/opt/gcc/mpfr/2.4.2
 --with-gmp=/opt/gcc/gmp/4.3.2 --with-sysroot=
 Thread model: posix
 gcc version 4.6.0 20110325 (Cray Inc.) (GCC)
 }}}

 As suggested by Jurko earlier today when we did a bit of debugging,
 the following was tried on the trunk of Boost build.  All commands
 below are executed within the v2/engine directory.

 Now, the culprit appears to be the expand() function in function.c.
 For testing we use a file, let's call it jamtest.jam, containing only
 these lines:
 {{{
 local a = one two three ;
 ECHO /$(a)/ ;
 }}}
 Then the following commands:
 {{{
 $ ./build.sh -d3 --release > /tmp/build-d3-release
 $ ./bin.linuxx86_64/bjam -f jamtest.jam
 }}}
 gives
 {{{
 /one/
 don't know how to make all
 ...found 1 target...
 ...can't find 1 target...
 }}}
 but
 {{{
 $ ./build.sh -d3 --debug > /tmp/build-d3-debug
 $ ./bin.linuxx86_64.debug/bjam -f jamtest.jam
 }}}
 gives
 {{{
 /one/ /two/ /three/
 don't know how to make all
 ...found 1 target...
 ...can't find 1 target...
 }}}
 which is what we expected -- so clearly, the 'release' version is
 faulty. (BTW, the build-d3-release and build-d3-debug files can be
 found in the pastebins  '''pastebin.com/M2njiNEK'''  and
 '''pastebin.com/038qcgFF''' respectively).

 Now, if we insert the following lines just before the line  "while ( --i
 >= 0)"
 {{{
    if (--i >= 0) {
       side_effect = i;
    }
    ++i;
 }}}
 and add
 {{{
    static int side_effect;
 }}}
 just before the function declaration, we then get:
 {{{
 $ ./build.sh -d3 --release > /tmp/build-d3-release
 $ ./bin.linuxx86_64/bjam -f jamtest.jam
 /one/ /two/ /three/
 don't know how to make all
 ...found 1 target...
 ...can't find 1 target...
 }}}
 and
 {{{
 $ ./build.sh -d3 --debug > /tmp/build-d3-debug
 $ ./bin.linuxx86_64.debug/bjam -f jamtest.jam
 /one/ /two/ /three/
 don't know how to make all
 ...found 1 target...
 ...can't find 1 target...
 }}}
 that is, correct in both release and debug modes.


 To me, it smells compiler bug, but as this is a system where I cannot
 "just update" the compiler, I am wondering if there are other
 solutions.  I have a feeling that it is the loop/while/goto construct
 that's complicating matters.

 BTW, the problem is not present with Boost 1.49, but both in 1.51 and
 trunk.  Of course, function.c is not present in 1.49, so that figures.

 I'd __really__ like to get on 1.51, so any suggestions on how to
 proceed are most welcome.

 Best regards

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7212#comment:14>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.