For a CROSS_TOOLCHAIN=powerpc64-gcc based 11.0-CURRENT previously built via WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= and for which delete-old had cleaned out the 4.2.1 gcc and for which a rebuild is attempted with...
make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \ WITHOUT_LLDB= \ WITH_GCC_BOOTSTRAP= WITH_GCC= WITH_GNUCXX= \ WITHOUT_BOOT= WITHOUT_LIB32= \ buildworld buildkernel \ KERNCONF=GENERIC64vtsc-NODEBUG \ TARGET=powerpc TARGET_ARCH=powerpc64 using... # more /etc/src.conf CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=gcc CXXFLAGS+=-I/usr/include/c++/v1 LDADD+=-L/usr/lib -lc++ NO_WERROR= It turns out that lib/csu/powerpc64/ still tries to use the gcc command: CC='gcc -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1' mkdep -f .depend -a -I/usr/srcC/lib/csu/powerpc64/../common -I/usr/srcC/lib/csu/powerpc64/../../libc/include -std=gnu99 /usr/srcC/lib/csu/powerpc64/crt1.c /usr/srcC/lib/csu/powerpc64/crti.S /usr/srcC/lib/csu/powerpc64/crtn.S ... /usr/bin/mkdep: gcc: not found That stops the build. lib/csu/powerpc64/Makefile reports... # XXX: See the log for r232932 as to why the above -mlongcall is needed. Since # clang doesn't support -mlongcall, and testing shows a clang linked with a # clang-built csu segfaults, this must currently be compiled with gcc. Once # clang supports -mlongcall, or we get a fixed ld, this can be revisited. CC:= gcc COMPILER_TYPE:= gcc So this lead to another after-booted-as-gcc-4.9.1-based type of oddity... Currently I'm having /usr/bin/gcc and /usr/bin/g++ be manually placed symbolic links to the powerpc64-gcc programs, much like I've directed /usr/lib/libstdc++.a and /usr/lib/libstdc++.so to reference the matching libc++ file in the same directory in order to avoid complaints about not finding -lstdc++ when I attempt the above make command. I've noticed that /usr/bin/cc and /usr/bin/c++ are still there for the powerpc64-gcc experimental sequence that I've gone through and they are still gcc 4.2.1. So I could point gcc and g++ to those to better match the old context. But I'm exploring avoiding gcc 4.2.1 as much as I reasonably can. I'm still avoiding building clang because a quick try got lost of error reports, such as reports of attempts to use deleted functions. That would seem to make an independent exploration direction. For now I'm just checking on having a way to rebuild again but from the powerpc64-gcc (4.9.1) build, this time including WITH_GCC_BOOTSTRAP= and WITH_GCC= and WITH_GNUCXX= but avoiding their use. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
