Re: build failures after stdlib update

Garrett Cooper schrieb am 2010-03-21:
> 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

hw.machine: amd64
hw.model: Intel(R) Pentium(R) Dual  CPU  E2160  _at_ 1.80GHz
hw.physmem: 2122203136

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

yes.

also i've attached by kernel conf, my make.conf and my src.conf.

> Thanks,
> -Garrett

-- 
Alexander Best