Date: Thu, 19 Mar 2015 05:13:01 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Subject: lib/csu/powerpc64/ requires/uses gcc command; does not use CC, XCC, or the like; its Makefile explains what caused the choice... Message-ID: <E2060E11-5228-4934-83EF-C7D5C0733F3B@dsl-only.net>
next in thread | raw e-mail | index | archive | help
For a CROSS_TOOLCHAIN=3Dpowerpc64-gcc based 11.0-CURRENT previously = built via WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D 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=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ WITHOUT_LLDB=3D \ WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GNUCXX=3D \ WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using... # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/include/c++/v1 LDADD+=3D-L/usr/lib -lc++ NO_WERROR=3D It turns out that lib/csu/powerpc64/ still tries to use the gcc command: CC=3D'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=3Dgnu99 = /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:=3D gcc COMPILER_TYPE:=3D 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=3D = and WITH_GCC=3D and WITH_GNUCXX=3D but avoiding their use. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E2060E11-5228-4934-83EF-C7D5C0733F3B>