Date: Thu, 09 Nov 2017 08:29:36 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Message-ID: <bug-223551-29464-gqXWJAlE8h@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-223551-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-223551-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 Mark Millard <markmi@dsl-only.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markmi@dsl-only.net --- Comment #1 from Mark Millard <markmi@dsl-only.net> --- (In reply to sid from comment #0) I expect that there is a misinterpretation of the https://wiki.freebsd.org/ExternalToolchain wording. (Easily done.) I think that https://wiki.freebsd.org/ExternalToolchain does not well indicate what context it material applies in vs. what context is does not: XCC, XCXX, XCPP, XAS, etc. do not replace all uses of CC, CPP, AS, etc. in all contexts. The description: The XCC approach works with top level build targets (buildworld, buildkerne= l, etc) and overrides common make variables such as CC, CXX, and AS during the cross building portions of the build with values specified by the XCC, XCPP, XAS, etc variables. (end description) sounds like all uses of CC, CXX, AS, and the like are replaced --but that is wrong and would not work for cross-builds. For example, for amd64 -> aarch64 (cortex-A53) cross builds I've used one compiler as the "for host" CC/CXX/CPP and another compiler and its tool chain as the "cross compiler to target" XCC/XCPP/. . . for a cross build context. The cross-compiler tools can not be used for everything because some host software is also built for later use in the overall buildworld that is happening on the host. Some recursive makes replace uses of CC/CXX/CPP and the like with uses of XCC/XCXX/XCPP (for example). But other make activity uses the original definitions above (or the defaults for what is not specified). I've even done examples of a gcc host compiler (and its toolchain) and a separate gcc cross compiler (and its tool chain), avoiding the system compiler for both aspects. That is a type of example where things have to start with CC/CXX/CPP/. . . vs. XCC/XCXX/XCPP/. . . being distinct and the initial CC/CXX/CPP/. . . do have to be used but are not the default (system compiler tied). [devel/*-xtolchain-gcc's are not setup for this fully automatically: they are only the cross-compiler/toolchain part of it.] I'll supply one example for a cross-build that has both CC/CXX/CPP and XCC/XCXX/XCPP/XAS/. . . assignments and needs the distinctions: (The example is for 12.0 but I've done such 11.x and for 10.x in the past. This does use the system compiler/toolchain as the host-targetting compiler/toolchain.) # more ~/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++ XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # From based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif (In some respects the above is explicit about some things that each devel/*-xtoolchain-gcc sets up to do automatically.) So ultimately I think the specifics of any example of a possible bad substitution need to be reported, including the inputs (such as the above), the actual invocation of make, and the bad commands that resulted during a build. With that much context things can be checked and which parts are messed up identified. The submittal is far to generic to identify anything specific that might be wrong. I'll note that I use this stuff extensively for amd64, powerpc64, powerpc, aarc64, and armv7 and cross building amd64 -> (each of the other 4). It seems to work correctly for me and last I tried it devel/*-xtoolchain-gcc based builds were working (and they use this stuff too, but presume the system-compiler for the host targeting part of buildworld). I started doing such things before the devel/*-xtoolchain-gcc's were put in place. --=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-223551-29464-gqXWJAlE8h>