Date: Thu, 09 Nov 2017 23:45:54 +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-2wWYl6eMsV@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 --- Comment #6 from Mark Millard <markmi@dsl-only.net> --- (In reply to sid from comment #5) So, for whatever reason, you want to: buildworld buildkernel in a way that does not build a system compiler or toolchain in the process, neither for internal use of the stages of the build, nor for what would be in the system after installworld. Also you do not want to use any pre-existing system compilers or system tool chain to do this activity but instead use a devel/llvm* . Sound right? (The ports conventions do not really apply to buildworld, although there likely is some overlap.) I used to do this sort of thing for powerpc64 (self hosted), although before devel/llvm*'s time. As I remember I had it build system-clang but not use system-clang. (At the time clang was broken in big ways for powerpc64 so the compiler was basically unusable.) I had it build various things just to prove that the builds could complete, even if they were otherwise unused. As I remember I had to do things to force the system include files and libraries to be used for what I used as the substitute for the "host system compiler/toolchain". The files from the compiler's own environment were not appropriate/sufficient. In more modern terms this would have been using lang/gcc7 and its tool chain as the "host system compiler/toolchain" and devel/powerpc64-gcc and its tool chain as the "cross compiler/toolchain", both targeting powerpc64 (on a powerpc64 context). (Originally it was gcc49 instead of gcc7.) May be the below will help, even though it is not exactly what you are after. Not adjusting the material for devel/llvm40 or devel/llvm50 but modernizing the content some and making it reference amd64 and be appropriate for adm64 (and its set up for 12.0): (preumes lang/gcc7 and devel/adm64-xtoolchain-gcc are installed, dependencies included; still shows building clang materials; I've not tested the below) # more /root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerpc64-host TO_TYPE=3Damd64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3D${TO_TYPE} TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC TARGET=3Damd64 .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 WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_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 # # # 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 # # # For FROM (host) stages . . . # From gccXY (such as gcc7 but not xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc7 -L/usr/lib CXX=3Denv C_INCLUDE_PATH=3D/usr/include CPLUS_INCLUDE_PATH=3D/usr/include/c= ++/v1 /usr/local/bin/g++7 -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp7 .export CC .export CXX .export CPP AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/objcopy OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/objdump RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bi= n/ranlib SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/= size #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/strings STRINGS=3D/usr/local/bin/strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif If the X<NAME>'s would be the same as the non-X <NAME>'s then the X<NAME> variants should not need definitions for amd64 -> amd64 (as I remember): they are only needed when the content is distinct. I do not remember the details but if I remember right at the time trying to turn off both clang and gcc fully in buildworld was odd in some way and I avoided doing so. It may be that one of them always built anyway and I choose to build clang. --=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-2wWYl6eMsV>