From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 19:07:30 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 36136106567A for ; Tue, 23 Mar 2010 19:07:30 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D49628FC1C for ; Tue, 23 Mar 2010 19:07:29 +0000 (UTC) Received: by pxi12 with SMTP id 12so356987pxi.14 for ; Tue, 23 Mar 2010 12:07:29 -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 :content-transfer-encoding; bh=uiCZquKk+NnTA4fSohRvq4CqFR6ufkcsI+tO7dRGfZI=; b=do0+LhcE/NVIh9ZOaU9IXiYIHj6Vd1MdVWnmvixZsJG4NUY95PNaKV27w3sR43dE9I BPZQVOGB/if6NqxCO7jQqJFS53gWtptBExnSjII8GjLF+b9PaPzy6WOvyLdoQosapNAS BEpy5GPGhcsCD+z1/PnApxsf0HSou3RMspDu8= 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:content-transfer-encoding; b=YcD3/ljtKtKEBxLHcW5KH77WPNlzKWsmx9g4YGBmDOxzpO8YCd5+S/DkBsF/FpV2oQ q0lUo/iODc20JHhTKaDIRP2Pxy01Ymka10timjq5ywCpld0UIR8+pvucFjbH6JiKDTNG L9G/3zzIy4w3W1Kxunui5N3ImFguNNyklrUnQ= MIME-Version: 1.0 Received: by 10.114.87.9 with SMTP id k9mr7377287wab.222.1269371249315; Tue, 23 Mar 2010 12:07:29 -0700 (PDT) In-Reply-To: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> References: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> Date: Tue, 23 Mar 2010 12:07:29 -0700 Message-ID: <7d6fde3d1003231207v2b60002cl7ba49e22bb0b7559@mail.gmail.com> From: Garrett Cooper To: Scot Hetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , 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: Tue, 23 Mar 2010 19:07:30 -0000 On Tue, Mar 23, 2010 at 11:19 AM, Scot Hetzel wrote: > On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote= : >> i don't think conf/112997 and the issue where gcc segfaults are directly >> related to each other: >> >> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune= =3Dnative >> /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=3D//'` to d= etermine >> gcc's idea of the appropriate -mtune value. that command however segfaul= ts. so >> this doesn't really help. > > The command runs correctly with a properly built gcc: > > # gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 | grep > mtune | sed -e 's/.*mtune=3D//' > generic > >> >> 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=3Dnati= ve` >> examples. for me `make` prints the same no matter what CPUTYPE is set to= : >> >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnative >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnocona >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Di386 >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dlalalala >> amd64 sse2 sse >> >> ..oh and of course i ran these commands with no CPUTYPE set in make.conf= . ;) >> > > If I run the same commands as above, I get similar results: > > # make -V MACHINE_CPU -DCPUTYPE=3Dnative > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dk8 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dnocona > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Di386 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dlala > amd64 sse2 sse > > But if I run the commands without the "-D", it shows the problem correctl= y: > > # make -V MACHINE_CPU CPUTYPE=3Dnative > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dk8 > k8 3dnow amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dnocona > sse3 amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Di386 > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dlalala > unknown amd64 sse2 sse mmx > # grep CPUTYPE /etc/make.conf /etc/src.conf > grep: /etc/src.conf: No such file or directory > > This was run under a Feb 28th -CURRENT. > > Now here is something strange. =A0Defining CPUTYPE in /etc/src.conf has > no effect on the output of MACHING_CPU. > > /etc/src.conf: 1 lines, 11 characters. > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > amd64 sse2 sse > /etc/src.conf:CPUTYPE=3Dk8 > > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > k8 3dnow amd64 sse2 sse mmx > /etc/make.conf:CPUTYPE=3Dk8 CPUTYPE can and should be defined in make.conf; it has been this way since the "beginning of time" (tongue in cheek). src.conf gets sourced in bsd.own.mk and make.conf gets sourced in sys.mk. I'll leave it to you to trace down which gets called first and in what order the logic gets evaluated, but I'm pretty sure it's doing the wrong thing when you put CPUTYPE in src.conf. The other thing to keep in mind is that -VCPUTYPE and -DCPUTYPE are evaluated differently: -D variable Define variable to be 1, in the global context. ... -V variable Print make's idea of the value of variable, in the global con- text. Do not build any targets. Multiple instances of this option may be specified; the variables will be printed one per line, with a blank line for each null or undefined variable. So I think that the example code is probably incorrect for -D ;). Thanks, -Garrett