svn commit: r254217 - head/sys/conf

[Ian Lepore]

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 at wand:/tmp # cat /tmp/foo
> >         #!/bin/sh -
> >         echo ${0}
> >         
> >         root at wand:/tmp # cat /tmp/Makefile 
> >         all:
> >                 @echo "Sourcing /tmp/foo..."; \
> >                 . /tmp/foo
> >         
> >         root at 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