>Number: 185480 >Category: misc >Synopsis: WORLDTMP first in PATH during installworld >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 05 03:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Nathan Dorfman >Release: 10.0-RC4 r260251 >Organization: >Environment: FreeBSD server 10.0-RC4 FreeBSD 10.0-RC4 #0 r260251: Sat Jan 4 15:48:21 EST 2014 na@server:/mnt/obj/usr/src/sys/GENERIC amd64 FreeBSD hudson 10.0-RC4 FreeBSD 10.0-RC4 #0 r260251: Sat Jan 4 18:18:03 EST 2014 na@client:/mnt/obj/mips.mips64/usr/src/sys/ERL mips
>Description: Disclaimer: I don't know much about this stuff, but after posting it here: http://lists.freebsd.org/pipermail/freebsd-mips/2014-January/003227.html I was asked to submit a PR, so here it is. This only causes failures if one tries to installworld on a different platform than buildworld was run on, but I suspect it may be silently hiding unintentional behavior in the other, more usual cases. The various subdirs of WORLDTMP (bin, usr/bin, usr/sbin, and so on) are the first elements of PATH during installkernel/installworld. Is this intentional? A couple of things suggest maybe not. The first is that WORLDTMP contains a toolchain for MACHINE_ARCH, even if you are cross-compiling by setting TARGET_ARCH. So, if you later try to install the crossbuilt kernel/world on the TARGET_ARCH machine, it will try to execute binaries built for the build machine, and fail: cc: Exec format error make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 9: warning: "cc --version" returned non-zero status This is easily remedied by either deleting WORLDTMP between build and install, or changing its definition in Makefile.inc1 to include ${MACHINE_ARCH} in the name before buildworld, so it won't be found by an installworld with a different MACHINE_ARCH. I'm not sure this is the right fix, though, as it leaves installkernel/world with only the existing installed root (/bin, /usr/bin, ...) in its PATH. The second one is a bit more glaringly obvious. After the above workaround is used, installworld fails a little later: install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib install: exec(strip): No such file or directory The PATH here again begins with the root at WORLDTMP, but ends not with the system root but /tmp/install.3aqj2XwQ. I noticed that installworld had just created this directory, and simply neglected to put strip in it, easily fixed by adding strip to the list of ITOOLS= in Makefile.inc1. However, under normal circumstances, nothing in this new directory is ever used, since everything is found in WORLDTMP first. Can that be right? We just went through the trouble of creating and populating a directory we don't intend to use? It seemed more likely that the intent is to use it, and that WORLDTMP is first in the PATH by mistake. >How-To-Repeat: server# uname -m amd64 server# cd /usr/src && svn diff && svn info | egrep '^URL|Revision' URL: svn://svn0.us-east.freebsd.org/base/releng/10.0 Revision: 260251 server# export MAKEOBJDIRPREFIX=/mnt/obj server# rm -rf $MAKEOBJDIRPREFIX server# TARGET=mips TARGET=mips64 make KERNCONF=ERL buildworld buildkernel client# uname -m mips client# mount | grep /usr server:/usr/src on /usr/src (nfs, read-only) server:/mnt/obj/mips.mips64 on /usr/obj (nfs, read-only) client# cd /usr/src && make KERNCONF=ERL installkernel installworld >Fix: If it's intentional that WORLDTMP is first in the PATH, then: 1. why are we bothering to build IROOT? 2. can it at least be redefined to include ${MACHINE_ARCH} in the name, so it won't break later installs run on a different arch? 3. if this is to be fully supported, then I guess a version of WORLDTMP needs to be compiled for the TARGET_ARCH as well when cross-building. If it isn't intentional... well. I guess it's a lot simpler then. :) >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
