From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 20 21:17:37 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 08183BD for ; Fri, 20 Mar 2015 21:17:37 +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 B41ACD28 for ; Fri, 20 Mar 2015 21:17:35 +0000 (UTC) Received: (qmail 19632 invoked from network); 20 Mar 2015 21:17:29 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Mar 2015 21:17:29 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 20 Mar 2015 17:17:29 -0400 (EDT) Received: (qmail 10081 invoked from network); 20 Mar 2015 21:17:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Mar 2015 21:17:28 -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 CB0301C43AE; Fri, 20 Mar 2015 14:17:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc: -pg compile gets ../libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault Date: Fri, 20 Mar 2015 14:17:26 -0700 Message-Id: To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML 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: Fri, 20 Mar 2015 21:17:37 -0000 It turns out that I had to rebuild powerpc64-gcc after booting into the = powerpc64-gcc based installed world (and kernel). The below notes start = from before that rebuild of powerpc64-gcc. Basic context (more detail later): > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (So this is was bootstrapped via a buildworld buildkernel with = CROSS_TOOLSCHAIN=3Dpowerpc64-gcc involved.) > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 WITHOUT_BOOT=3D and WITHOUT=3DLIB32=3D were used for the above build. Also WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D . And WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D = WITHOUT_LLDB=3D . > # 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 > WITH_LIBCPLUSPLUS=3D > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ > NO_WERROR=3D The active build with the compiler crash was working on: > 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 WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 in the above context. But it turns out that I can show the problem in a = much quicker form then waiting for the rebuild to get to that point. The problem: For the quicker form of test: having done buildworld buildkernel from = the gcc 4.2.1 based powerpc64 SSD but using powerpc64-gcc via = CROSS_TOOLCHAIN=3Dpowerpc64-gcc (much like the above)... installworld (and installkernel) to another SSD that is effectively = initially a copy of the gcc 4.2.1 based one with the powerpc64-gcc = present. Then reboot into that newer SSD. Using the above /etc/src.conf = then try something like: > mkdir -p /tmp/lib \ > && mkdir -p /tmp/usr/lib \ > && mkdir -p /tmp/usr/srcC/lib/libcxxrt \ > && cd /usr/srcC/lib/libcxxrt/ \ > && MAKEOBJDIRPREFIX=3D/tmp \ > make CROSS_TOOLCHAIN=3Dpowerpc64-gcc DIRPRFX=3Dlib/libcxxrt/ = DESTDIR=3D/tmp obj depend all install The point being to get the involved .cc files to be compiled in the = normal way, including in the form that uses -pg. This which works fine on the original SSD (given that SSD's = /etc/src.conf that uses = CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 and = LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ ). The result for -pg for contrib/libcxxrt/terminate.cc on the gcc 4.9.1 = based SSD was consistently: > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc: In = function 'void std::terminate()': > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc:36:7: = internal compiler error: Segmentation fault > void terminate() > ^ > no stack trace because unwind library not available > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** [terminate.po] Error code 1 >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > 1 error >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > *** [all_subdir_libcxxrt] Error code 2 Rebuilding powerpc64-gcc from the booted powerpc64-gcc based SSD (in my = case via gcc5 use and portmaster) and trying again shows that the = rebuild has removed the above crash status for -pg use. (Until the powerpc64-gcc port avoids failing for file name/placement = problems when used on powerpc64's, having powerpc64-gcc rebuild itself = in such a context is a no-go: It fails between removing itself and = putting back the newer materials. That does not leave enough materials = around for a portmaster with -C to continue after a hand adjusted group = of file names/placements.) There appears to be some form of binary incompatibility for -pg that = requires the powerpc64-gcc rebuild to get the new binary context right. = Once it matches it seems fine. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # 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 > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 in CXXFLAGS and = the like. This is despite the /usr/srcC/Makefile.inc1 logic (that ends = up inactive for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.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 > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during buildworld/buildkernel activity. > # See /etc/src.conf for example buildworld/buildkernel values. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net