Re: build failures after stdlib update

From: Alexander Best <alexbestms_at_wwu.de>
Date: Sun, 21 Mar 2010 01:55:01 +0100 (CET)
ok. i think i finally solved this riddle. the cause for the problem seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
been using the 'native' keyword for years now and never had any problems with
it, but it seems a recent commit broke 'native' as CPUTYPE. for me this is
100% reproducable:

1. put 'CPUTYPE = native' in /etc/make.conf
2. build and install gnu/usr.bin/cc
3. do 'buildkernel' or 'buildworld' and observe the segfault. for some reason
this always occurs in lib/libc/string/strlen.c (r205108). i've tested this
with older version of libc.so (built 22. Feb) and got the same result. so i
assume this is not a libc problem, but a problem with gcc tripping over some
code in libc. i have no clue however why this happend just now and not
earlier. i don't think there has been a recent commit to gcc.

to solve this there are two ways:

1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you compile
everything just fine even with a gcc that has itself been built with 'CPUTYPE
= native'.
2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the gcc version
that has been built this way will compile everything just fine even with
'CPUTYPE = native'. the only way to break this is to go and compile gcc again
with the CPUTYPE set to 'native'.

so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to 'native' will
give you a broken gcc!

cheers.
alex

ps: i don't know if the situation is the same on archs != amd64. i could only
test this on amd64.
Received on Sat Mar 20 2010 - 23:55:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC