Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it
On 2017-Aug-29, at 3:08 PM, Mark Millard wrote: > On 2017-Aug-29, at 2:38 PM, Bryan Drewery wrote: > >> On 8/29/2017 2:35 PM, Mark Millard wrote: >>> In a command command such as: >>> >>> poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null -M >>> /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src -S >>> /usr/src/ -v 11.1-STABLE >>> >>> the -x is silently ignored. I added the "build_native_xtools" into >>> the /usr/local/share/poudriere/jail.sh code to have it contain: >> >> I consider '-m null' to be a read-only operation on the provided path. >> Poudriere did not build it, so I would rather not force a build >> procedure on it for native-xtools either. >> >> On the otherhand, if we store the native-xtools files outside of the >> jail path then it will not be a problem. > > Okay. I was just looking for a way to deal with local > experimental patches in the system and/or ports rather > than building from official materials, checking how > things seem to go for builds. > > I ended up with the following nxb* directories in > /usr/obj/. . . for my context: > > /usr/obj/powerpc.powerpc/nxb > /usr/obj/arm.armv6/nxb > /usr/obj/arm64.aarch64/nxb > /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin > /usr/obj/powerpc.powerpc64/nxb I should also have compared and contrasted with my buildworld/buildkernel directory trees: # ls -dlT /usr/obj/*/*.* drwxr-xr-x 3 root wheel 3 Aug 13 15:16:17 2017 /usr/obj/amd64_clang/amd64.amd64 drwxr-xr-x 3 root wheel 3 Aug 29 01:22:29 2017 /usr/obj/armv7_clang/arm.armv6 drwxr-xr-x 3 root wheel 3 Aug 29 02:12:29 2017 /usr/obj/cortexA53_clang/arm64.aarch64 drwxr-xr-x 3 root wheel 3 Aug 29 02:45:54 2017 /usr/obj/cortexA57_clang/arm64.aarch64 drwxr-xr-x 3 root wheel 3 Aug 28 16:34:43 2017 /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64 drwxr-xr-x 3 root wheel 3 Aug 29 01:48:58 2017 /usr/obj/powerpcvtsc_clang/powerpc.powerpc drwxr-xr-x 3 root wheel 3 Aug 29 02:38:08 2017 /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc (For that last clang built a gcc421 bootstrap compiler.) These were built with the likes of: # more ~/sys_build_scripts.amd64-host/make_armv7_nodebug_clang_bootstrap-amd64-host.sh kldload -n filemon && \ script ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host" \ WITH_META_MODE=yes \ MAKEOBJDIRPREFIX="/usr/obj/armv7_clang" \ make $* So the "nxb" directories were outside my build trees. The DESTDIRs listed that had "nxb-bin" directories were just for the poudriere use in the first place. For other uses I'd have created separate install trees with their own names. > However, for example, I did the powerpc ones in > the order (as an experiment that I did not expect > to "work"): > > /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin > > and the second reused the material from the first -x . In other > words: the native compiler ended up being based on clang for the > later gcc421 based jail attempt. > > A similar point goes for the pair (in order): > > /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin > > in that the A57 one bound to the prior A53 -x content. > > I'm not claiming a problem, just something to know to > expect to avoid. (My 32-bit powerpc activity has lead > to building things based on both compilers because of > the kernel build only working for gcc421-based builds. > Such odd combinations are likely rare.) > >>> >>> null) >>> JAILFS=none >>> FCT=build_native_xtools >>> ;; >>> >>> in order to avoid this. >>> >>> A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and >>> -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src >>> in my context) and the later bulk build for it seems to be >>> working fine for building lang/gcc7 (as a test). So far: > . . . === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/
Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it
On 2017-Aug-29, at 2:38 PM, Bryan Drewery wrote: > On 8/29/2017 2:35 PM, Mark Millard wrote: >> In a command command such as: >> >> poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null -M >> /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src -S >> /usr/src/ -v 11.1-STABLE >> >> the -x is silently ignored. I added the "build_native_xtools" into >> the /usr/local/share/poudriere/jail.sh code to have it contain: > > I consider '-m null' to be a read-only operation on the provided path. > Poudriere did not build it, so I would rather not force a build > procedure on it for native-xtools either. > > On the otherhand, if we store the native-xtools files outside of the > jail path then it will not be a problem. Okay. I was just looking for a way to deal with local experimental patches in the system and/or ports rather than building from official materials, checking how things seem to go for builds. I ended up with the following nxb* directories in /usr/obj/. . . for my context: /usr/obj/powerpc.powerpc/nxb /usr/obj/arm.armv6/nxb /usr/obj/arm64.aarch64/nxb /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin /usr/obj/powerpc.powerpc64/nxb However, for example, I did the powerpc ones in the order (as an experiment that I did not expect to "work"): /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin and the second reused the material from the first -x . In other words: the native compiler ended up being based on clang for the later gcc421 based jail attempt. A similar point goes for the pair (in order): /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin in that the A57 one bound to the prior A53 -x content. I'm not claiming a problem, just something to know to expect to avoid. (My 32-bit powerpc activity has lead to building things based on both compilers because of the kernel build only working for gcc421-based builds. Such odd combinations are likely rare.) >> >>null) >>JAILFS=none >>FCT=build_native_xtools >>;; >> >> in order to avoid this. >> >> A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and >> -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src >> in my context) and the later bulk build for it seems to be >> working fine for building lang/gcc7 (as a test). So far: . . . === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it
On 8/29/2017 2:35 PM, Mark Millard wrote: > In a command command such as: > > poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null -M > /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src -S > /usr/src/ -v 11.1-STABLE > > the -x is silently ignored. I added the "build_native_xtools" into > the /usr/local/share/poudriere/jail.sh code to have it contain: I consider '-m null' to be a read-only operation on the provided path. Poudriere did not build it, so I would rather not force a build procedure on it for native-xtools either. On the otherhand, if we store the native-xtools files outside of the jail path then it will not be a problem. > > null) > JAILFS=none > FCT=build_native_xtools > ;; > > in order to avoid this. > > A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and > -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src > in my context) and the later bulk build for it seems to be > working fine for building lang/gcc7 (as a test). So far: > > [00:00:16] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.10.1 > [00:01:02] [01] [00:00:46] Finished ports-mgmt/pkg | pkg-1.10.1: Success > [00:01:03] [01] [00:00:00] Building print/indexinfo | indexinfo-0.2.6 > [00:01:03] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 > [00:01:06] [01] [00:00:03] Finished print/indexinfo | indexinfo-0.2.6: Success > [00:01:06] [01] [00:00:00] Building devel/gettext-runtime | > gettext-runtime-0.19.8.1_1 > [00:01:35] [01] [00:00:29] Finished devel/gettext-runtime | > gettext-runtime-0.19.8.1_1: Success > [00:01:35] [01] [00:00:00] Building devel/gettext-tools | > gettext-tools-0.19.8.1 > ^C[00:03:18] Error: Signal SIGINT caught, cleaning up and exiting > [00:03:18] Cleaning up > > [00:00:10] [01] [00:00:00] Building devel/gettext-tools | > gettext-tools-0.19.8.1 > [00:00:10] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 > [00:02:12] [01] [00:02:02] Finished devel/gettext-tools | > gettext-tools-0.19.8.1: Success > [00:02:13] [01] [00:00:00] Building devel/gmake | gmake-4.2.1_1 > [00:02:54] [01] [00:00:41] Finished devel/gmake | gmake-4.2.1_1: Success > [00:12:44] [02] [00:12:34] Finished lang/perl5.24 | perl5-5.24.2: Success > [00:12:44] [01] [00:00:00] Building devel/p5-Locale-gettext | > p5-Locale-gettext-1.07 > [00:13:13] [01] [00:00:29] Finished devel/p5-Locale-gettext | > p5-Locale-gettext-1.07: Success > [00:13:14] [01] [00:00:00] Building misc/help2man | help2man-1.47.4 > [00:13:37] [01] [00:00:23] Finished misc/help2man | help2man-1.47.4: Success > [00:13:37] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 > ^C[00:14:43] Error: Signal SIGINT caught, cleaning up and exiting > [00:14:43] Cleaning up > > [00:00:17] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 > [00:03:03] [01] [00:02:46] Finished print/texinfo | texinfo-6.4_1,1: Success > [00:03:03] [01] [00:00:00] Building math/gmp | gmp-6.1.2 > [00:03:03] [02] [00:00:00] Building devel/m4 | m4-1.4.18,1 > [00:04:02] [02] [00:00:59] Finished devel/m4 | m4-1.4.18,1: Success > [00:04:03] [02] [00:00:00] Building devel/bison | bison-3.0.4,1 > [00:04:28] [01] [00:01:25] Finished math/gmp | gmp-6.1.2: Success > [00:04:28] [01] [00:00:00] Building math/mpfr | mpfr-3.1.5_1 > [00:04:45] [02] [00:00:42] Finished devel/bison | bison-3.0.4,1: Success > [00:04:48] [01] [00:00:20] Finished math/mpfr | mpfr-3.1.5_1: Success > [00:04:48] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 > [00:04:48] [02] [00:00:00] Building math/mpc | mpc-1.0.3 > [00:05:00] [02] [00:00:12] Finished math/mpc | mpc-1.0.3: Success > [00:20:29] [01] [00:15:41] Finished devel/binutils | binutils-2.28,1: Success > [00:20:30] [01] [00:00:00] Building lang/gcc7 | gcc7-7.2.0 > > So I expect that the change is appropriate. > > > [Unfortunately qemu-ppc64-static seems to not work: > the qemu-ppc64-static process just sits and eats CPU time > with increasing SIZE when qemu-ppc64-static is put to use > via poudriere. This blocks progress.] > > === > Mark Millard > markmi at dsl-only.net > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
