From owner-svn-src-head@FreeBSD.ORG Tue Aug 13 17:02:22 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8818B479; Tue, 13 Aug 2013 17:02:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49B1F2520; Tue, 13 Aug 2013 17:02:21 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V9HzA-000Aoj-Qe; Tue, 13 Aug 2013 17:02:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7DH2IhS035999; Tue, 13 Aug 2013 11:02:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX185kQTvWIYby9fkR0k4cMI1 Subject: Re: svn commit: r254217 - head/sys/conf From: Ian Lepore To: Glen Barber In-Reply-To: <20130813153222.GL2432@glenbarber.us> References: <201308111357.r7BDvF7H065442@svn.freebsd.org> <1376407389.3320.209.camel@revolution.hippie.lan> <20130813153222.GL2432@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Aug 2013 11:02:17 -0600 Message-ID: <1376413337.3320.224.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:02:22 -0000 On Tue, 2013-08-13 at 11:32 -0400, Glen Barber wrote: > On Tue, Aug 13, 2013 at 09:23:09AM -0600, Ian Lepore wrote: > > On Sun, 2013-08-11 at 13:57 +0000, Glen Barber wrote: > > > Author: gjb > > > Date: Sun Aug 11 13:57:14 2013 > > > New Revision: 254217 > > > URL: http://svnweb.freebsd.org/changeset/base/254217 > > > > > > Log: > > > Use realpath(1) to determine the location of the newvers.sh script, > > > since the current working directory might not be what is expected, > > > causing svn{,lite}version to fail to find ${0} (itself). > > > > > > Submitted by: Dan Mack > > > > > > Modified: > > > head/sys/conf/newvers.sh > > > > > > Modified: head/sys/conf/newvers.sh > > > ============================================================================== > > > --- head/sys/conf/newvers.sh Sun Aug 11 11:33:48 2013 (r254216) > > > +++ head/sys/conf/newvers.sh Sun Aug 11 13:57:14 2013 (r254217) > > > @@ -96,7 +96,7 @@ for dir in /usr/bin /usr/local/bin; do > > > # Run svnversion from ${dir} on this script; if return code > > > # is not zero, the checkout might not be compatible with the > > > # svnversion being used. > > > - ${dir}/svnversion $(basename ${0}) >/dev/null 2>&1 > > > + ${dir}/svnversion $(realpath ${0}) >/dev/null 2>&1 > > > if [ $? -eq 0 ]; then > > > svnversion=${dir}/svnversion > > > break > > > @@ -105,7 +105,7 @@ for dir in /usr/bin /usr/local/bin; do > > > done > > > > > > if [ -z "${svnversion}" ] && [ -x /usr/bin/svnliteversion ] ; then > > > - /usr/bin/svnliteversion $(basename ${0}) >/dev/null 2>&1 > > > + /usr/bin/svnliteversion $(realpath ${0}) >/dev/null 2>&1 > > > if [ $? -eq 0 ]; then > > > svnversion=/usr/bin/svnliteversion > > > else > > > > This is still not working for me. I don't see how it could be working > > properly for anyone. > > > > The newvers.sh isn't run from the make rules, it's sourced into the > > rules. In that context, ${0} appears to resolve to simply "sh" or > > "/bin/sh" (depending on host OS version) not the name of the script that > > was sourced. Here's a minimal example: > > > > root@wand:/tmp # cat /tmp/foo > > #!/bin/sh - > > echo ${0} > > > > root@wand:/tmp # cat /tmp/Makefile > > all: > > @echo "Sourcing /tmp/foo..."; \ > > . /tmp/foo > > > > root@wand:/tmp # make > > Sourcing /tmp/foo... > > /bin/sh > > > > There are other references to $0 within newvers.sh, and if you add a > > 'set -x' to the beginning of the script you can see that they all > > resolve to /bin/sh, which seems to imply that there's some stuff that's > > working by accident in that script when it's sourced in. > > > > I tested this with a 'buildkernel', not running the script directly. In > my tests, I did add 'set -x' so I could verify the right thing was being > done, which in my case, it was. > > Can you 'set -x' in the script, and provide the output of 'make -s > builkdkernel' ? > > Glen > It fails for me during buildworld (I haven't gotten to buildkernel yet). This is a cross-build of armv6 from i386, if that matters. When I use "make -s" the build fails immediately in "building an up to date make" because it somehow has $DESTDIR/usr/lib/libc.a as a dependency for bmake/unit-tests, and clearly that isn't going to exist before installworld has created it (when DESTDIR is other than / which is always is for me). For some reason I can't even begin to figure out, I don't get that error with the -s left off. Hrm, I just noticed I get the same bmake build error at the beginning with and without the -s, the difference is that without -s it ignores the error and keeps building. Seems like a different bug. So, leaving the make -s problems aside, a regular "make buildworld" results in http://people.freebsd.org/~ian/make.buildworld.log (the failure is around line 6178). I don't know what's different between make with and without -s but perhaps it somehow toggles this problem. BTW, I'm seeing this problem at r254281, and did not see it at r253965. -- Ian