Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Aug 2017 15:29:29 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        Bryan Drewery <bdrewery@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
Subject:   Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it
Message-ID:  <2A6F3F8A-2957-477D-8AD5-B0494598F7F8@dsl-only.net>
In-Reply-To: <52C6B6AA-EAAD-41A1-A07F-C773D9F33315@dsl-only.net>
References:  <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> <eb14e667-aedd-d45c-0875-655289350923@FreeBSD.org> <52C6B6AA-EAAD-41A1-A07F-C773D9F33315@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Aug-29, at 3:08 PM, Mark Millard <markmi@dsl-only.net> wrote:


> On 2017-Aug-29, at 2:38 PM, Bryan Drewery <bdrewery@FreeBSD.org> =
wrote:
>=20
>> On 8/29/2017 2:35 PM, Mark Millard wrote:
>>> In a command command such as:
>>>=20
>>> 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
>>>=20
>>> the -x is silently ignored. I added the "build_native_xtools" into
>>> the /usr/local/share/poudriere/jail.sh code to have it contain:
>>=20
>> 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.
>>=20
>> On the otherhand, if we store the native-xtools files outside of the
>> jail path then it will not be a problem.
>=20
> 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.
>=20
> I ended up with the following nxb* directories in
> /usr/obj/. . . for my context:
>=20
> /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/n=
xb-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-ho=
st.sh=20
kldload -n filemon && \
script =
~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-amd64-host=
-$(date +%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" =
SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-hos=
t" \
WITH_META_MODE=3Dyes \
MAKEOBJDIRPREFIX=3D"/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"):
>=20
> /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin
> /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin
>=20
> 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.
>=20
> A similar point goes for the pair (in order):
>=20
> /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin
> /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin
>=20
> in that the A57 one bound to the prior A53 -x content.
>=20
> 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.)
>=20
>>>=20
>>>       null)
>>>               JAILFS=3Dnone
>>>               FCT=3Dbuild_native_xtools
>>>               ;;
>>>=20
>>> in order to avoid this.
>>>=20
>>> A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and
>>> -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src=20
>>> in my context) and the later bulk build for it seems to be
>>> working fine for building lang/gcc7 (as a test). So far:
> . . .


=3D=3D=3D
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-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A6F3F8A-2957-477D-8AD5-B0494598F7F8>