Re: installworld broken - osreldate.h: permission denied

 Bezüglich Ian Lepore's Nachricht vom 28.09.2013 19:19 (localtime):
> On Sat, 2013-09-28 at 15:09 +0200, Joel Dahl wrote:
>> Hi,
>>
>> Fresh HEAD. installworld from read-only /usr/obj and /usr/src:
>>
>> /usr/src/include/iconv.h osreldate.h /usr/include
>> install: osreldate.h: Permission denied
>> *** Error code 71
>>
>> Stop.
>> make[4]: stopped in /usr/src/include
>> *** Error code 1
>>
>> Everything was working fine 2 weeks ago, so it's a recent breakage.
>>
> Okay, I just accidentally created conditions for this error on my
> system...  I checked in a change to newvers.sh while a buildworld was
> running, which led to a situation where newvers.sh was newer than
> osreldate.h at the end of the buildworld.  Then an installworld tried to
> regenerate osreldate.h due to its dependency on newvers.sh, which would
> fail if the obj was readonly at that point.
>
> I think we could see if something similar applies for you if you use
> this command:
>
>   make -dm installworld SUBDIR_OVERRIDE=include
>
> And we'd be looking for the end of the output to be something like:
>
> Examining _libiconv_compat.h...
> modified 10:51:18 Sep 28, 2013...up-to-date
> Make_Update: _libiconv_compat.h
> inspect parent buildincludes: flags 0, type 18001, made 0, unmade 95 - not needed
> inspect parent _INCSINS: flags 9, type b000001, made 1, unmade 1 - unmade children
> Examining osreldate.h...
> modified 10:39:21 Sep 28, 2013...modified before source /local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh...out-of-date
> env ECHO="echo"  MAKE="/local/build/staging/freebsd/head/obj/local/build/staging/freebsd/head/src/make.i386/bmake"  NEWVERS_SH=/local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh  PARAM_H=/local/build/staging/freebsd/head/src/include/../sys/sys/param.h  SYSDIR=/local/build/staging/freebsd/head/src/include/../sys  sh /local/build/staging/freebsd/head/src/include/mk-osreldate.sh
> env: not found
> *** [osreldate.h] Error code 127
>
> The "env: not found" is what I got instead of a permission denied, and
> probably has something to do with me cross-building amd64 10.0 from an
> i386 8.x machine.  I think that's where you'd see the permission error.
>
> If the same sort of thing is happening for you, then all that's left is
> to figure out why osreldate.h is out of date at install time, and how to
> handle things if that's the case.

Thanks for your suggestion how to best find out what's going on.
I have the same problem you observed (env: not found), not the
permission problem the thread opener had.

For any reason, not relevant at this point, my
${src}/sys/conf/newvers.sh is newer than 'include/osreldate.h' under
$OBJDIRPREFIX/i386.i386/….

Now in 'include/Makefile', "sh ${MK_OSRELDATE_SH}" should be called by
'env' in target 'osreldate.h vers.c:'.
Problem is, that PATH has sevaral bin-sbin directories under
"$OBJDIRPREFIX/…/tmp/" _and_ "$INSTALLTMP", and none of them provides 'env'.
The latter is filled with target 'distributeworld installworld:' in
Makefile.inc1, with $ITOOLS.

The following additional tools are missing in ITOOLS
to make recreating osreldate.h work at installworld stage:
env, hostname, mktemp and touch

So a patch to work arround that issue looks like this:
--- src/Makefile.inc1.orig 2014-09-25 17:36:16.000000000 +0200
+++ src/Makefile.inc1 2014-09-25 17:47:14.000000000 +0200
_at__at_ -697,9 +697,9 _at__at_
.endif

ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
- date echo egrep find grep id install ${_install-info} \
- ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ date echo egrep env find grep hostname id install ${_install-info} \
+ ln lockf make mkdir mktemp mtree ${_nmtree_itools} mv pwd_mkdb \
+ rm sed sh sysctl test touch true uname wc ${_zoneinfo}

#
# distributeworld

I have no idea if there's a better way, but if these tools are not to be
added, the check for outdated osreldate.h should be disabled because
recreation at install stage is not possible without. At least this is
true for compiling 9.3-i386 on 10-stable-amd64.

-Harry