From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 02:28:15 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 396FA106566B for ; Sun, 21 Mar 2010 02:28:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7985C8FC0C for ; Sun, 21 Mar 2010 02:28:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id EAA24068; Sun, 21 Mar 2010 04:28:11 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NtAte-0009sM-PA; Sun, 21 Mar 2010 04:28:10 +0200 Message-ID: <4BA58439.8070304@icyb.net.ua> Date: Sun, 21 Mar 2010 04:28:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Alexander Best References: <201003171654.15017.ken@mthelicon.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 02:28:15 -0000 on 21/03/2010 02:55 Alexander Best said the following: > 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. Interestingly enough, there have recent commits to lib/libc/string/strlen.c. > 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! -- Andriy Gapon