Boost logo

Boost-Build :

Subject: Re: [Boost-build] Anyone know what's up with bug #7212?
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-08-29 11:07:32

   Hi all.

> On 29.08.2012 16:10, Kim Rasmussen wrote:
>> Ie. the output of
>> ECHO /$(globalize)/ ;
>> is
>> /peek/
>> and the output of
>> ECHO /modules.$(globalize)/ ;
>> is
>> /modules.peek/
> Sounds like variable expansion is very, very, broken. I don't have any
> such problems on trunk, on Linux.
> Steven, any ideas?

   Kim & I have debugged the issue a bit.

   The problem seems to have been introduced by some of Steven's
variable expansion changes 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 codebase,
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 aroung the middle of that
function which never seems to get entered on the target system. Wierd
thing is that if we add the following code just before that while loop:

     if ( --i >= 0 ) { printf( "%d\n", 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.

   Kim had to leave now for a while but will try to connect back in a
few hours.

   I 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 in the bug ticket comments 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).

   I'll try to rewrite the expand() function mentioned above to not use
'goto', as my guess would be that this is confusing the optimizer and
causing it to optimize away the whole 'while ( --i >= 0 )' loop. Steven,
as you're the original author of this code - have any hints on why it
was written so and ideas on what could be done to avoid this issue?

   Volodya, do you have any suggestions on how we can check whether this
is the case? Some gdb magic perhaps? Or some gcc option to make it
generate assembler code? If you'll be around in a few hours, can you
give me a ping on ICQ?

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at