From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 00:55: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 CC1CD106564A for ; Sun, 21 Mar 2010 00:55:05 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFFB8FC08 for ; Sun, 21 Mar 2010 00:55:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,280,1267398000"; d="scan'208";a="28927954" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 01:55:02 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 536671B0768; Sun, 21 Mar 2010 01:55:02 +0100 (CET) Date: Sun, 21 Mar 2010 01:55:01 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <201003171654.15017.ken@mthelicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: 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 00:55:06 -0000 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! cheers. alex ps: i don't know if the situation is the same on archs != amd64. i could only test this on amd64.