Date: Fri, 20 Mar 2015 18:04:53 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-toolchain@freebsd.org Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc when building with WITH_CLANG= defined: include/c++/v1/ problems... Message-ID: <B6A43BF6-7C1E-434F-B27B-963EC3AC58F5@dsl-only.net>
next in thread | raw e-mail | index | archive | help
CROSS_TOOLCHAIN=3Dpowerpc64-gcc will not automatically use =
/usr/include/c++/v1/ paths or /usr/lib/ paths. And those paths are only =
appropriate sometimes. Other times paths such as =
/usr/obj/usr/srcC/tmp/usr/include/c++/v1 and =
/usr/obj/usr/srcC/lib/libc++ are appropriate.=20
The later material concludes that =
_bootstrap-tools-lib/clang/libllvmtablegen and the like do not have a =
well controlled c++ header/library(?) environment for =
CROSS_TOOLCHAIN=3D... use.
/etc/src.conf lines such as:
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 =
-L/usr/obj/usr/srcC/lib/libc++/.
are a problem in general. So far I've not found a good hook for making =
the distinctions for CROSS_TOOLSCHAIN=3Dpowerpc64-gcc :
> # Actually only appropriate for for _includes _libraries _depend =
everything build32 :
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 =
-L/usr/obj/usr/srcC/lib/libc++/.=20
> #
> # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools =
_cleanobj _obj _build-tools _cross-tools :
> CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/.
> #
> # But for self-hosting in a CROSS_TOOLSCHAIN=3D... like manor =
sometimes having both can work.
Note: My context happens to be self-hosting: powerpc64 using =
CROSS_TOOLCHAIN=3Dpowerpc64-gcc. I've taken advantage of that status in =
the details of what I've done but I do not know what I'd do in a true =
non-self-hosting context.
Even for WITHOUT_CLANG=3D I've used
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 =
-L/usr/obj/usr/srcC/lib/libc++/.=20
in /etc/src.conf because, for example, without it atf-c++ ended 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 <ostream>
> ^
> compilation terminated.
This without-ostream case was despite the /usr/srcC/Makefile.inc1 logic =
(that ends up inactive/ineffective for some reason at the time):
> .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
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...
> # spans being-built and (failing finding those directories) live and =
so for
> # -DNO_CLEAN after being-built ones are in place depends on =
self-hodsting
> # where the two are sufficient compatibile.
> #
> # I've used .../. paths so I can tell use of these from other sources =
of paths.
> #
> # Actually only appropriate for for _includes _libraries _depend =
everything build32 :
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 =
-L/usr/obj/usr/srcC/lib/libc++/.=20
> #
> # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools =
_cleanobj _obj _build-tools _cross-tools :
> #CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/.
> #
> # But for self-hosting in a cross-tools like manor sometimes having =
both can work.
> #
> NO_WERROR=3D
was used as context for:
> make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \
> WITH_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
The problem:
Without the /etc/src.conf line (or equivalent):
> CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/.
when I turned on WITH_CLANG=3D (see above) in order to try to build =
clang during buildworld it got...
> --- _bootstrap-tools-lib/clang/libllvmtablegen ---
> CC=3D'/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc ' mkdep -f =
.depend -a =
-I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include =
-I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib
> /llvm/tools/clang/include =
-I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen =
-I. =
-I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clan=
g/include -DLLVM_ON_UNI
> X -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS =
-DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" =
-DLLVM_HOST_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT
> =3D\"\" -I/usr/obj/usr/srcC/tmp/legacy/usr/include =
-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 -std=3Dc++11 =
=
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err=
or.c
> pp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Mai=
n.cpp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Rec=
ord.cpp /usr/srcC/lib/clang/libllvmtablegen
> /../../../contrib/llvm/lib/TableGen/SetTheory.cpp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Str=
ingMatcher.cpp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib
> /TableGen/TableGenBackend.cpp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGL=
exer.cpp =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGP=
arser.cpp=20
> In file included from =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT=
/SmallVector.h:17:0,
> from =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT=
/ArrayRef.h:14,
> from =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Sup=
port/SourceMgr.h:19,
> from =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Tab=
leGen/Error.h:18,
> from =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err=
or.cpp:15:
> =
/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT=
/iterator_range.h:22:19: fatal error: utility: No such file or directory
> #include <utility>
> ^
> compilation terminated.
Removing
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1=
1 -L/usr/obj/usr/srcC/lib/libc++/.
from /etc/src.conf does not make the c++11 headers available at that =
time. Only adding something like:
> CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/.
did. (Luckily for what I'd doing having both CXXFLAGS+=3D... works out =
okay.)
I did not notice anything that suggested an intended way to deal with =
the two contexts for CROSS_TOOLCHAIN=3Dpowerpc64-gcc use.
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.
CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for =
WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was =
a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing =
just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural =
fit.
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). Originally I was =
investigating how far I could get without involving gcc 4.2.1 and what =
would be involved.
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+=3D1=
1 -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 <ostream>
> ^
> 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/ineffective 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 the buildworld/buildkernel activities:
> # _includes _libraries _depend everything build32.
> # See /etc/src.conf for example buildworld/buildkernel
> # values for that context.
> #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 from a booted world that had been built =
based on powerpc64-gcc in a gcc 4.2.1 world.)
> # 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've 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6A43BF6-7C1E-434F-B27B-963EC3AC58F5>