From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 11:43:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2EAD106566B for ; Sun, 21 Mar 2010 11:43:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by mx1.freebsd.org (Postfix) with ESMTP id C6C738FC08 for ; Sun, 21 Mar 2010 11:43:21 +0000 (UTC) Received: by pxi14 with SMTP id 14so2770022pxi.15 for ; Sun, 21 Mar 2010 04:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0hD3dTIcjG3Y2G9K2doTvn44B3yb3Bb5Cwg37sC47bI=; b=oHM5yakuVSAGJzIYXMI+pvgRUkWqYBgoMRwJ1QBvJRjmOozDTe1JhNzqMLVszvBnc9 Shr+3xnkz7hANERldtIfm/A5988m62y2sAQhlBhof3lBiqX0Pub+7zgG4QXnPbT5E9ak LzB0j8Y8n8yrtOT5wjwBE/P/hvgnHD40QSQPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BiWh0q7ULrcKgUwjOpWwLdIiPnYbXr5iPiWaldZGuPJYrUcXQOwErzEFQt9BEocSTm aNuZKqcLRHZJAIWDbuQdZ/5xFImG20huzmLlhzQrlLzknUIYtiwk5e/T8pg+7CTCbJeN mPG5QW+P8StpZ66TDzXxQBLca9225nwmhKQEs= MIME-Version: 1.0 Received: by 10.142.210.12 with SMTP id i12mr1845535wfg.62.1269171801266; Sun, 21 Mar 2010 04:43:21 -0700 (PDT) In-Reply-To: References: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> Date: Sun, 21 Mar 2010 04:43:21 -0700 Message-ID: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 11:43:22 -0000 On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best wrote: > Garrett Cooper schrieb am 2010-03-21: >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best >> 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 =3D native' in /etc/make.conf >> > 2. build and install gnu/usr.bin/cc >> > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for >> > =A0 =A0some 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 >> > =A0 =A0compile >> > everything just fine even with a gcc that has itself been built >> > with 'CPUTYPE >> > =3D native'. >> > 2. build and install gnu/usr.bin/cc with 'CPUTYPE =3D nocona'. the >> > =A0 =A0gcc version >> > that has been built this way will compile everything just fine even >> > with >> > 'CPUTYPE =3D 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! > >> =A0 =A0 What does -march=3Dnative yield in your case? There haven't been >> =A0 =A0 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 cou= ldn't > figure out what the cause of it is. only a few points i'd like to point o= ut: > > 1. this is very easily reproducible for me. i just need to set CPUTYPE=3D= native > in my /etc/make.conf and everything that gets linked against libc and use= s 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=3Dnative in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > 2. there seems to be a connection with strlen.c because gcc alaways segfa= ults > here. also i've been using CPUTYPE=3Dnative for years now and never had a= ny > problems with it. for me the segfault always happens in: > > #0 =A0strlen (str=3DVariable "str" is not available. > ) at /usr/src/lib/libc/string/strlen.c:100 > 100 =A0 =A0 =A0 =A0 =A0 =A0 va =3D (*lp - mask01); > > it would be nice if people with arch i386 and amd64 could try to reproduc= e > this (i believe the other archs don't support CPUTYPE=3Dnative). again th= e > easiest way to trigger this (you don't need to edit your /etc/make.conf f= or > this) should be running: > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > for now i'm using the attached patch to prevent myself from shooting me i= n the > foot again. ;) Works for me *shrugs*: $ gcc -v -x c -E -mtune=3Dnative /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=3D= 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 @ 2.67GHz hw.physmem: 12852424704 2. Do you have IA32 compatibility installed (now referred to as FREEBSD_32)= ? Thanks, -Garrett