powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc when building with WITH_CLANG= defined: include/c++/v1/ problems...

Sat Mar 21 01:04:57 UTC 2015

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 at 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 at 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