Re: build failures after stdlib update

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. ;)

cheers.
alex

> Cheers,
> -Garrett

-- 
Alexander Best