From owner-freebsd-current@FreeBSD.ORG Tue Mar 8 00:06:05 2011 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 D9A7910656DC for ; Tue, 8 Mar 2011 00:06:05 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2E78FC17 for ; Tue, 8 Mar 2011 00:06:05 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id CD94F13F8C9; Tue, 8 Mar 2011 01:06:03 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gke-HHNigz7K; Tue, 8 Mar 2011 01:06:01 +0100 (CET) Received: from [10.9.8.3] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 1C97113F8BD; Tue, 8 Mar 2011 01:06:01 +0100 (CET) Message-ID: <4D7572E8.2060607@FreeBSD.org> Date: Tue, 08 Mar 2011 01:06:00 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <20110307205957.GA47557@freebsd.org> <20110307212922.GW78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110307212922.GW78089@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: George Liaskos , freebsd-current@freebsd.org Subject: Re: r219385 build error. 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: Tue, 08 Mar 2011 00:06:05 -0000 This actually does not happen at the bootstrap stage, but when building 32-bit compat libs under amd64. It looks like the system compiler is used here instead (should it be this way, isn't it a bug somewhere around Makefile.inc1?). Yes, building + installing world without this optimization makes it work again (you can build the whole world). And generally, I am putting the LIB32CPUFLAGS in question, why are we using here a 64-bit cpu type at all? In bsd.cpu.mk we map nocona and core2 to prescott for i386. Dňa 07.03.2011 22:29, Kostik Belousov wrote / napísal(a): > On Mon, Mar 07, 2011 at 11:19:40PM +0200, George Liaskos wrote: >>> What process did you follow to get here? >> I did a make toolchain followed by make buildworld. >> >>> that's because the latest gcc commits have support for core2 and thus it no >>> longer is being expanded to nocona. please note that having core2 in make.conf >>> has always been *wrong*. hence the need to reset it to nocona. >>> the best way to fix this would be to set CPUYTYPE?=native. if you want core2 >>> support now's the chance to actually get it. just update world and you can use >>> CPUTYPE?=core2 and this time it *really* is supported. ;) >> I saw the relevant commits about core2, this is the reason i decided >> to do a rebuild. >> I didn't know that core2 was wrong, it's in the make.conf >> documentation, "native" it's not and after serious googling i found >> out that i should actually avoid it. >> >> I always believed that core2 was there [make.conf] as a future proof >> upgrade path for when the base toolchain actually supports core2. >> >> So, should i use native cputype? > You did not shown the actual point where the error was raised. > Applying some psychic powers, I could guess that it happens at the > bootstrap stage. And this would be reasonable indeed, since bootstrap > needs to use the system compiler, until the new cross toolchain is > ready. And obviously system compiler not yet supports -march=core2, > since you are only compiling the code that supports. > > Of course, all this assuming that error indeed happens at bootstrap, > and the referenced commit does not introduce regressions, which I > think is the case. > > I believe the solution for you would be to remove any CPU model settings > from make.conf, make and install new world, then try new buildworld > with desired settings. As a side note, I do not believe that you would > get any measurable changes.