Date: Thu, 17 Nov 2016 03:23:17 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 214596] make broken on 11.0-Stable unless /usr/obj/prod/110101/D/CORE2/usr/src/make.amd64/bmake exists Message-ID: <bug-214596-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214596 Bug ID: 214596 Summary: make broken on 11.0-Stable unless /usr/obj/prod/110101/D/CORE2/usr/src/make.amd64/bmake exists Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: dewayne@heuristicsystems.com.au make on 11.0Stable generates either signal 12 or signal 4 after a: make wor= ld, kernel,reboot sequence. After investigating the cause there is a difference between make on 10.3S and 11.0S. Using this command (based on a debug of a 10.3S make) on an 11.0S enables correct function: # make -m /usr/src/share/mk -f Makefile.inc1 TARGET=3Damd64 TARGET_ARCH=3Da= md64 MK_META_MODE=3Dno check-old-dirs This can be identified when comparing the output from 10 and 11 for=20 # cd /usr/src; make check-old-files >/tmp/make.log 2>&1 10.3S reveals (note the "test -x"): .MAKE.PATH_FILEMON =3D /dev/filemon # this is a reference, the next line = is relevant cd /usr/src; PATH=3D/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=3Dmake `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake= || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=3Damd64 TARGET_ARCH=3Damd64 MK_META_MODE=3Dno check-old-files Execute: 'cd /usr/src; PATH=3D/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=3Dmake= `test -x /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bm= ake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=3Damd64 TARGET_ARCH=3Damd64 MK_META_MODE=3Dno check-old-files' while on 11.0 .MAKE.PATH_FILEMON =3D /dev/filemon cd /usr/src; PATH=3D/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=3Dmake /usr/obj/usr/src/make.amd64/bmake -m /usr/src/share/mk -f Makefile.inc1=20 TARGET=3Damd64 TARGET_ARCH=3Damd64 MK_META_MODE=3Dno check-old-files Execute: 'cd /usr/src; PATH=3D/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=3Dmake /usr/obj/usr/src/make.amd64/bmake -m /usr/src/share/mk -f Makefile.inc1=20 TARGET=3Damd64 TARGET_ARCH=3Damd64 MK_META_MODE=3Dno check-old-files' Use case=20 1. When building on one system and installing onto another, make fails 2. When building a suite of machines for multiple platforms (which is what = we typically do), there is NO /usr/obj. For example when we bulid systems we have: /usr/obj/prod/110101/D/CORE2/usr/src/make.amd64/bmake which isn't found even on the machine that the "system" is built. At least = the DESTDIR could be referenced to find bmake or better use the code from 10.3S In short - when there is NO /usr/obj/usr/src/make.amd64/bmake that's right. When there is no /usr/obj/usr/src/make.amd64/bmake, make bre= aks. And after a full install and everything works and we remove /usr/obj prior = to a rebuild (our typical behaviour), make barfs. How we go to the discovery of this new feature: 1. Following the instructions in /usr/src/Makefile (for 11.0S source) on a = 10.3 system 1a. make buildworld # - ok 1b. make buildkernel # - ok=20 1c. installkernel # - seems ok except for kldxref ... install -T release -o root -g wheel -m 555 g_mouse.ko /boot/kernel/ --- afterinstall --- kldxref /boot/kernel kldxref: unknown metadata record 4 in file atp.ko kldxref: unknown metadata record 4 in file atp.ko ... reboot 2. Reboots to standalone # Umm, not ok. sh - signal 12 # cd /usr/src/; make installworld signal 12 3. Reboot standalone and fiddle. Reboots to multiuser # cd /usr/src/; make installworld signal 4 Ok - rebuild on a separate 10.3S machine, tar the files and copy to the hos= t.=20 This now works and kldxref /boot/kernel does its job. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-214596-8>