From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 19 12:13:06 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18947BDD for ; Thu, 19 Mar 2015 12:13:06 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2F5787D for ; Thu, 19 Mar 2015 12:13:05 +0000 (UTC) Received: (qmail 20755 invoked from network); 19 Mar 2015 12:13:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 12:13:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 08:13:03 -0400 (EDT) Received: (qmail 17926 invoked from network); 19 Mar 2015 12:13:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 12:13:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 380A81C43AA; Thu, 19 Mar 2015 05:13:01 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: lib/csu/powerpc64/ requires/uses gcc command; does not use CC, XCC, or the like; its Makefile explains what caused the choice... Date: Thu, 19 Mar 2015 05:13:01 -0700 Message-Id: To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 12:13:06 -0000 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