From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 04:48:00 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 29ED2106566C for ; Sun, 21 Mar 2010 04:48:00 +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 F2E6E8FC12 for ; Sun, 21 Mar 2010 04:47:59 +0000 (UTC) Received: by pxi14 with SMTP id 14so2683382pxi.15 for ; Sat, 20 Mar 2010 21:47:59 -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; bh=LFg4dJUrirA9VDm5F7pjXF8gyLAYR8dNbW0LXcAMz2s=; b=YR31/t6gHWkKNiuQoOX+n2u5Hm2rACoPL6HtmkqfFbliOhS657gH5BVP9ASVvQPuJi VJRcsLb92dFJQWaine9HHZ9lupsyoULiCXTJmBb77pKhLzVQaQohEp/I90u7E7afhcIM XChis3yD3+rNoEwBYexkJcEwWXFKYycDwuyfc= 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; b=wGv3LBbdIBDvjX5u4kJkz9WSIn3NpIAgSOtqxahPLmcbIzW+oD5CJizZPyYRayOnzr 1V1V7YgXAuNxouAl0linSWZLI1FAwck5sj3bEu9fp9Bou+tqYao0VJ8b7ZgLW/fPN3yN A3weOeTTDypPhDuXsF0em+8DTE4UVd8iZsA1s= MIME-Version: 1.0 Received: by 10.142.152.34 with SMTP id z34mr800250wfd.176.1269146879561; Sat, 20 Mar 2010 21:47:59 -0700 (PDT) In-Reply-To: References: <201003171654.15017.ken@mthelicon.com> Date: Sat, 20 Mar 2010 21:47:59 -0700 Message-ID: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 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 04:48:00 -0000 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. Cheers, -Garrett