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 15:21:30

#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 jurko):

 It would be great if some more people affected by this problem would come
 back to us so we can compare their environment with Kims.

 And here's a status update after doing some interactive debugging with
 Kim.

 The problem seems to have been introduced by some of the variable
 expansion changes made between Boost library 1.49 & 1.50 releases but the
 effects are ***really really wierd***. My guess is that the changed code
 is somehow triggering a compiler/optimizer bug.

 The problematic function in new code is expand(), located in the
 function.c module. In the original 1.49 Boost library release code-base,
 that function did not exist and its work seems to have been done by the
 var_string() function in the variable.c module (and possibly some other
 function in the later removed expand.c module - did not check).

 There we have a 'while ( --i >= 0 )' loop around the middle of that
 function which never seems to get entered on the target system. Weird
 thing is that if we add the following code just before that while loop:
 {{{
     if ( --i >= 0 ) { printf( "%d\n", i ); }
     ++i;
 }}}
 Then everything works fine.

 On the other hand, if we leave in the same code but without the printf()
 call - then we're back to the original problem - most likely due to the
 optimizer recognizing and removing the dummy code.

 We still have not done the following on the target system:
     - tried using the debug Boost Jam build
     - collected version information (Linux/gcc/glibc)

 The 'warning' problem mentioned seems to be caused by the target system's
 include files (old version perhaps?) not declaring the strndup() function
 unless the _GNU_SOURCE symbol is defined, but that warning existed with
 Boost library 1.49 release and fixing it in the current trunk has no
 effect on the initial variable expansion problem. I'll fix that by
 rewriting the code to not use strndup() in the first place (will replace
 it with some malloc()/strncpy() combination).

 For more information on the planned expand() function changes - see the
 Boost Build mailing list.

 Hope this helps.

 Best regards,
     Jurko Gospodnetić


 _______________________________________________
 Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi

 /boost-build

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