From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 00:29:06 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 902DD106564A for ; Mon, 22 Mar 2010 00:29:06 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38D9B8FC12 for ; Mon, 22 Mar 2010 00:29:05 +0000 (UTC) Received: by vws1 with SMTP id 1so179582vws.13 for ; Sun, 21 Mar 2010 17:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=3QSOYfZrs/KIu//vEvB+5OHNCwau4MpJV5At9MramVA=; b=SJxqhCViypLQ6RcZwUrOZy59yZ3wSXml5nxuoMZONcQbbK6tgau4PDbNe/zmTeaGTs jUDz2nM3ZRpQymWDYXtwgZNg2F5L2zWja2U+MQvZyLLAU1eQ8I/WTrigsuz080en+NUK 7CzFaxURwVepjgKKWnGd6u3ZDh1AAMxWQbyHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=sOCvsGr8TL1bk2e2aKA82GK5q82lXEfPNSIHtcU/KeoafSlnWmtAld8lEfaQrCGzwd ktkOmpn82AOZceML3bNKRIah6N92YCBCWuMwbgicKgPEyVPeCL3x271ELFtd9NWo/4V9 D/2iqMy3pTWbcPfHsgaUjwY5ubXgXGg7+KrKA= Received: by 10.220.122.24 with SMTP id j24mr1970769vcr.28.1269217742591; Sun, 21 Mar 2010 17:29:02 -0700 (PDT) Received: from ppp-21.206.dialinfree.com (ppp-21.206.dialinfree.com [209.172.21.206]) by mx.google.com with ESMTPS id 31sm30488855vws.11.2010.03.21.17.28.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 17:29:01 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 20:29:16 -0400 From: jhell To: Alexander Best In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , 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: Mon, 22 Mar 2010 00:29:06 -0000 On Sun, 21 Mar 2010 07:00, alexbestms@ 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 = 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 > > Native is equal to CPUTYPE not being defined right ? So if the above is true why would you set CPUTYPE to native in the first place ? when you can just leave it unset and its equal to native. Nowhere in /usr/share/examples/etc/make.conf do I see a referance to this type of CPUTYPE so unless I am totally missing the point of this thread, I do not see a problem that has to be fixed. With all due respect, -- jhell