Date: Sat, 20 Mar 2010 21:47:59 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Alexander Best <alexbestms@wwu.de> Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update Message-ID: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> In-Reply-To: <permail-20100321005501f0889e84000020fd-a_best01@message-id.uni-muenster.de> References: <201003171654.15017.ken@mthelicon.com> <permail-20100321005501f0889e84000020fd-a_best01@message-id.uni-muenster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best <alexbestms@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.
Cheers,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1003202147i1af5969bi333b58db6430c100>