Re: [Boost-build] Compiling 1.34.1 on OpenSUSE 10.3

From: Ruediger Berlich (ruediger.berlich_at_[hidden])
Date: 2007-10-26 15:25:58

Hi,

from what I can see build.sh first creates a "jam0" which in turn manages
compilation the actual bjam executable. I can see that
the -fno-strict-aliasing is added in the compilation of jam0 if I update
build.sh the way you suggest. The flag does not appear in the console
messages during the compilation of the bjam executable:

gcc -fno-strict-aliasing -o bootstrap/jam0 command.c compile.c debug.c
expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c
lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c
pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c
modules.c strings.c filesys.c builtins.c pwd.c class.c native.c
w32_getreg.c modules/set.c modules/path.c modules/regex.c
modules/property-set.c modules/sequence.c modules/order.c execunix.c
fileunix.c
./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean
...found 1 target...
...updating 1 target...
[DELETE] clean
...updated 1 target...
./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root=
...found 47 targets...
...updating 1 target...
[COMPILE] bin.linuxx86/bjam
...updated 1 target...

And, as mentioned in another mail, if I call this new bjam executable, it
segfaults. jam0 runs fine, though. So up to now the only option seems to be 
"./build.sh gcc --debug".

Where would I have to add the -fno-strict-aliasing flag so that it is used
by jam0 for the compilation of bjam ?

Thanks and Best Regards,
Ruediger

Boris Gubenko wrote:
> Ruediger Berlich wrote:
>> I am particularly unsure whether the compiler bug you mention also
>> applies to the configuration of the actual library files (rather than
>> only bjam).
> 
> Only bjam.
> 
>> If so: where would I have to add the compiler flag ?
> 
> I'd have added it to boost/tools/jam/src/build.sh :
> 
>     gcc)
>     BOOST_JAM_CC="gcc -fno-strict-aliasing"
>     ;;
> 
> HTH,
>   Boris
> 
> ----- Original Message -----
> From: "Ruediger Berlich" <ruediger.berlich_at_[hidden]>
> To: <boost-build_at_[hidden]>
> Sent: Thursday, October 25, 2007 2:23 PM
> Subject: Re: [Boost-build] Compiling 1.34.1 on OpenSUSE 10.3
> 
> 
>> Hi there,
>>
>> thanks for the hints. Here is how I got the library to compile on
>> OpenSUSE 10.3 . Note that I did not have time to check whether everything
>> works yet.
>>
>> - made sure the python-devel package was installed (has the Python.h file
>> and is *not* installed by default!)
>> - Ran configure
>> - Went to the boost_1_34_1/tools/jam/src directory
>> - Ran "./build.sh gcc --debug"
>> - From the top directory
>> ran "./tools/jam/src/bin.linuxx86.debug/bjam
>> --user-config=user-config.jam"
>>
>> Probably the "configure" call was'nt even necessary in this case ?
>>
>> I am particularly unsure whether the compiler bug you mention also
>> applies to the configuration of the actual library files (rather than
>> only bjam).
>>
>> If so: where would I have to add the compiler flag ? BTW, I believe the
>> flag
>> is not called --fno-strict-alias , but  --fno-strict-aliasing
>>
>> Thanks and best Regards,
>> Ruediger
>>
>>
>>
>> Rene Rivera wrote:
>>> Vladimir Prus wrote:
>>>> On Wednesday 24 October 2007 18:27:30 Ruediger Berlich wrote:
>>>>> OpenSUSE 10.3 is still delivered with Boost 1.33.1 . Hence I've
>>>>> downloaded Boost 1.34.1 and tried to compile it. I ran the configure
>>>>> script and then make. The resulting bjam immediately dies with an
>>>>> error:
>>>>>
>>>>> ./tools/jam/src/bin.linuxx86/bjam  --user-config=user-config.jam
>>>>> /bin/sh: line 1:  2090
>>>>> Speicherzugriffsfehler  ./tools/jam/src/bin.linuxx86/bjam
>>>>> --user-config=user-config.jam
>>>>>
>>>>> "Speicherzugriffsfehler" means "memory access violation".
>>>>>
>>>>> This is on a Pentium-D dual-core system (4GB main memory) running with
>>>>> a 32-bit Linux kernel 2.6.22, g++ 4.2.1 .
>>>>
>>>> Rene,
>>>> does this sound like that alias analysis issue with g++ 4.2?
>>>
>>> Yep, it's the aliasing problem with gcc-4.2
>>>
>>>> Have we figured the
>>>> exact cause of this crash,
>>>
>>> Nope, other than it's a compiler bug.
>>>
>>>> and any approach for working it around?
>>>
>>> The only work around I know of is to compile a debug version, or with
>>> --fno-strict-alias, IIRC.
>>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build