CROSS_TOOLCHAIN=powerpc64-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.
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=... use.
/etc/src.conf lines such as:
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++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=powerpc64-gcc :
> # Actually only appropriate for for _includes _libraries _depend everything
> build32 :
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11
> -L/usr/obj/usr/srcC/lib/libc++/.
> #
> # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools
> _cleanobj _obj _build-tools _cross-tools :
> CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/.
> #
> # But for self-hosting in a CROSS_TOOLSCHAIN=... like manor sometimes having
> both can work.
Note: My context happens to be self-hosting: powerpc64 using
CROSS_TOOLCHAIN=powerpc64-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= I've used
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11
> -L/usr/obj/usr/srcC/lib/libc++/.
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} == gcc
> XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> -L${WORLDTMP}/../lib/libc++
> DEPFLAGS+= -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)
> ...
(So this is was bootstrapped via a buildworld buildkernel with
CROSS_TOOLSCHAIN=powerpc64-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= and WITHOUT=LIB32= were used for the above build.
Also WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= .
And WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= WITHOUT_LLDB= .
> # 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
> WITH_LIBCPLUSPLUS=
> #
> # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=powerpc64-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+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11
> -L/usr/obj/usr/srcC/lib/libc++/.
> #
> # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools
> _cleanobj _obj _build-tools _cross-tools :
> #CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/.
> #
> # But for self-hosting in a cross-tools like manor sometimes having both can
> work.
> #
> NO_WERROR=
was used as context for:
> make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= \
> WITH_LLDB= \
> WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
> WITHOUT_BOOT= WITHOUT_LIB32= \
> buildworld buildkernel \
> KERNCONF=GENERIC64vtsc-NODEBUG \
> TARGET=powerpc TARGET_ARCH=powerpc64
The problem:
Without the /etc/src.conf line (or equivalent):
> CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/.
when I turned on WITH_CLANG= (see above) in order to try to build clang during
buildworld it got...
> --- _bootstrap-tools-lib/clang/libllvmtablegen ---
> CC='/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/clang/include
> -DLLVM_ON_UNI
> X -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT
> =\"\" -I/usr/obj/usr/srcC/tmp/legacy/usr/include
> -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11 -std=c++11
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.c
> pp
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp
>
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cpp
> /usr/srcC/lib/clang/libllvmtablegen
> /../../../contrib/llvm/lib/TableGen/SetTheory.cpp
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/StringMatcher.cpp
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib
> /TableGen/TableGenBackend.cpp
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGLexer.cpp
>
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGParser.cpp
>
> 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/Support/SourceMgr.h:19,
> from
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/TableGen/Error.h:18,
> from
> /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.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+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu+=11
> -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+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/.
did. (Luckily for what I'd doing having both CXXFLAGS+=... works out okay.)
I did not notice anything that suggested an intended way to deal with the two
contexts for CROSS_TOOLCHAIN=powerpc64-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=powerpc64-gcc use does not allow -melf32ppc_fbsd for WITH_BOOT=
and WITH_LIB32= build activity to use. Even if there was a
powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing just the
WITH_BOOT= and WITH_LIB32= 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
>
> # 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=/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
> ...
that essentially duplicate the XCC, XCXX, XCPP assignments from
CROSS_TOOLCHAIN=powerpc64-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=powerpc64-gcc use...
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu+=11
> -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} == gcc
> XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> -L${WORLDTMP}/../lib/libc++
> DEPFLAGS+= -I${WORLDTMP}/usr/include/c++/v1
As for /etc/make.conf it looks like...
> # more /etc/make.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
> # 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+=-I/usr/include/c++/v1 -std=gnu++11 -L/usr/obj/usr/srcC/lib/libc++
> #
> #CC=/usr/local/bin/gcc5
> #CXX=/usr/local/bin/g++5
> #CPP=/usr/local/bin/cpp5
> #CC=/usr/local/bin/clang36
> #CXX=/usr/local/bin/clang++36
> #CPP=/usr/local/bin/clang-cpp36
> WRKDIRPREFIX=/usr/obj/portswork
> #WITH_DEBUG=
> MALLOC_PRODUCTION=
(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).
===
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"
