Re: build failures after stdlib update

On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best <alexbestms_at_wwu.de> wrote:
> Garrett Cooper schrieb am 2010-03-21:
>> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best <alexbestms_at_wwu.de>
>> wrote:
>> > 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!
>
>>     What does -march=native yield in your case? There haven't been
>>     any
>> recent commits to gcc, so I'm not sure whether or not that's the
>> issue. The libraries that I provided could have just been built from
>> a
>> sane system -- maybe it's something else that needs to be explored a
>> bit more closely to root cause the issue.
>
> i've experimented with setting CPUTYPE to native yesterday, but still couldn't
> figure out what the cause of it is. only a few points i'd like to point out:
>
> 1. this is very easily reproducible for me. i just need to set CPUTYPE=native
> in my /etc/make.conf and everything that gets linked against libc and uses the
> strlen() function won't compile due to gcc segfaulting. this is the case with
> /usr/src/bin/cat e.g. as well as kernel, world and probably lots of other
> stuff.
>
> also the following gcc command segfaults too (no need for setting
> CPUTYPE=native in this case, because -mtune gets set manually):
>
> gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
>
> 2. there seems to be a connection with strlen.c because gcc alaways segfaults
> here. also i've been using CPUTYPE=native for years now and never had any
> problems with it. for me the segfault always happens in:
>
> #0  strlen (str=Variable "str" is not available.
> ) at /usr/src/lib/libc/string/strlen.c:100
> 100             va = (*lp - mask01);
>
> it would be nice if people with arch i386 and amd64 could try to reproduce
> this (i believe the other archs don't support CPUTYPE=native). again the
> easiest way to trigger this (you don't need to edit your /etc/make.conf for
> this) should be running:
>
> gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
>
> for now i'm using the attached patch to prevent myself from shooting me in the
> foot again. ;)

Works for me *shrugs*:

$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]
 /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=generic
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
End of search list.
$ echo $?
0

Could you provide more specific details, i.e.:

1. Hardware specs:

$ sysctl hw.machine hw.model hw.physmem
hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU           W3520  _at_ 2.67GHz
hw.physmem: 12852424704

2. Do you have IA32 compatibility installed (now referred to as FREEBSD_32)?

Thanks,
-Garrett