Overall powerpc64-xtoolchain-gcc does not include its own libc++ for
powerpc64-gcc.
Overall, then, an as-is powerpc64-xtoolchain-gcc based powerpc/powerpc64 build
would need to be WITHOUT_CLANG= as far as I can tell. (buildworld/buildkernel
but excluding building the clang-based tool chain.)
Trying WITHOUT_CLANG= (in /etc/src.conf ) got further but failed with:
--- bt_split.So ---^M
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem
/usr/obj/usr/srcC/tmp/usr/include -L/usr/obj/usr/srcC/tmp/usr/lib -fpic -DPIC
-O2 -pipe -I/usr/srcC/lib/libc/include -I/usr/srcC/lib/libc/.
./../include -I/usr/srcC/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE
-I/usr/srcC/lib/libc/../../contrib/gdtoa
-I/usr/srcC/lib/libc/../../contrib/libc-vis -DINET6
-I/usr/obj/usr/srcC/lib/libc -I/us
r/srcC/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE
-I/usr/srcC/lib/libc/../libmd
-I/usr/srcC/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION
-I/usr/srcC/lib/libc/../../contrib/tzcode/st
dtime -I/usr/srcC/lib/libc/stdtime -I/usr/srcC/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN -I/usr/srcC/lib/libc/rpc -DYP -DNS_CACHING
-DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=gnu99 -fstack-
protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c /usr/srcC/lib/libc/db/btree/bt_split.c -o bt_split.So^M
...
--- bt_split.So ---^M
/usr/srcC/lib/libc/db/btree/bt_split.c: In function '__bt_split':^M
/usr/srcC/lib/libc/db/btree/bt_split.c:240:8: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]^M
bt_preserve(t, *(pgno_t *)bl->bytes) == RET_ERROR)^M
^^M
/usr/srcC/lib/libc/db/btree/bt_split.c: In function 'bt_broot':^M
/usr/srcC/lib/libc/db/btree/bt_split.c:548:7: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]^M
bt_preserve(t, *(pgno_t *)bl->bytes) == RET_ERROR)^M
^^M
...
--- bt_split.So ---^M
cc1: all warnings being treated as errors^M
*** [bt_split.So] Error code 1^M
^M
There may need to be more tailoring someplace before the
powerpc64-xtoolchain-gcc based builds can complete.
Is it known what tailoring is needed?
Also, as is probably expected, my use of TARGET=powerpc TARGET_ARCH=powerpc did
no good for targeting powerpc instead of powerpc64: it produces "ELF 64-bit
..." for what it does compile.
powerpc64-xtoolchain-gcc (really powerpc64-gcc) will not build on powerpc64: no
self hosting as stands. There is no powerpc-xtoolchain-gcc (yet?).
So it looks like once I know the tailoring required further experiments will
only be building powerpc64 builds from powerpc builds.
Another powerpc64-xtoolchain-gcc point that I noticed was that ${XSTRING} would
not find the strings file to execute. Details follow...
(I use /usr/srcC/ for 11C's /usr/src/ .)
/usr/local/powerpc64-freebsd/bin/ is missing strings but
/usr/srcC/Makefile.inc1 expects it to be there based on CROSS_BUNUTILS_PREFIX
pointing there:
# more /usr/local/share/toolchains/powerpc64-gcc.mk
XCC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
XCXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
XCPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
X_COMPILER_TYPE=gcc
# ls -FPal /usr/local/powerpc64-freebsd/bin/
total 11400
drwxr-xr-x 2 root wheel 512 Mar 13 12:55 ./
drwxr-xr-x 4 root wheel 512 Mar 13 12:55 ../
-r-xr-xr-x 2 root wheel 989796 Mar 13 12:55 ar*
-r-xr-xr-x 2 root wheel 1394156 Mar 13 12:55 as*
-r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld*
-r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld.bfd*
-r-xr-xr-x 2 root wheel 974520 Mar 13 12:55 nm*
-r-xr-xr-x 2 root wheel 1139108 Mar 13 12:55 objcopy*
-r-xr-xr-x 2 root wheel 1436356 Mar 13 12:55 objdump*
-r-xr-xr-x 2 root wheel 989800 Mar 13 12:55 ranlib*
lrwxr-xr-x 1 root wheel 32 Mar 13 12:55 size@ ->
../../bin/powerpc64-freebsd-size
-r-xr-xr-x 2 root wheel 1139112 Mar 13 12:55 strip*
So no "strings" but...
/usr/srcC/Makefile.inc1 prepends ${CROSS_BINUTILS_PREFIX} to ${STRINGS} to
create XSTRINGS:
XBINUTILS= AS AR LD NM OBJCOPY OBJDUMP RANLIB SIZE STRINGS
.for BINUTIL in ${XBINUTILS}
.if defined(CROSS_BINUTILS_PREFIX)
X${BINUTIL}?= ${CROSS_BINUTILS_PREFIX}${${BINUTIL}}
.else
X${BINUTIL}?= ${${BINUTIL}}
.endif
.endfor
So if a build later uses ${XSTRINGS} it will not find it in the file system for
powerpc64-xtoolchain-gcc.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-12, at 03:13 PM, Mark Millard <markmi at dsl-only.net> wrote:
Warner wrote:
> Is cc1plus the g++ compiler that is installed on your bootstrapped system, or
> is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help
> determine that. You may have to find it on your system (there’s likely 2) and
> pass it the -std=c++11 option to see which of them fail. We may have a leak /
> problem with mkdep that your unique setup is revealing.
The below details indicate that gcc 4.2.1's /usr/libexec/cc1plus was in use
when the message about -std=c++11 being unrecognized was generated for "make
WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc
TARGET=powerpc TARGET_ARCH=powerpc".
Details...
# which cc1plus
#
So no cc1plus is in my default path: it is being found another way.
Ingoring the /usr/src/... and /usr/obj/... paths that have a cc1plus...
$ find / -name cc1plus -print
/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus
...
/usr/libexec/cc1plus
...
No others.
$ ls -FPal /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1*
-r-xr-xr-x 1 root wheel 14582156 Mar 12 10:25
/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1*
-r-xr-xr-x 1 root wheel 15771164 Mar 12 10:25
/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus*
$ ls -FPal /usr/libexec/cc1*
-r-xr-xr-x 1 root wheel 6541860 Mar 10 23:21 /usr/libexec/cc1*
-r-xr-xr-x 1 root wheel 7115952 Mar 10 23:21 /usr/libexec/cc1plus*
$ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -v
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1/powerpc64-portbld-freebsd11.0"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1/backward"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/sys-include"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include
/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include-fixed
End of search list.
^C
$ /usr/libexec/cc1plus -v
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/include/gcc/4.2
/usr/include
End of search list.
^C
$ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -std=c++11
^C
$ /usr/libexec/cc1plus -std=c++11
cc1plus: error: unrecognized command line option "-std=c++11"
^C
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-12, at 02:33 PM, Warner Losh <imp at bsdimp.com> wrote:
Thanks Mark. :(
Is cc1plus the g++ compiler that is installed on your bootstrapped system, or
is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help
determine that. You may have to find it on your system (there’s likely 2) and
pass it the -std=c++11 option to see which of them fail. We may have a leak /
problem with mkdep that your unique setup is revealing.
Warner
> On Mar 13, 2015, at 5:42 AM, Mark Millard <mar...@dsl-only.net> wrote:
>
> Warner L. wrote about my attempt to use rpc64-xtoolchain-gcc/powerpc64-gcc in
> a powerpc (non-64) context that has no clang built:
>
>> Trying WITH_CLANG=t ...
>
> So I did...
>
> make WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain
> KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc
>
> This results in a different failure (cc1plus not understanding the -std=c++11
> option that it ends up being given):
>
> --------------------------------------------------------------
>>>> stage 1.2: bootstrap tools
> --------------------------------------------------------------
> ...
> mkdep -f .depend -a
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"powerpc-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
> ... <OMITTING MANY .cpp's> ...
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp
> cc1plus: error: unrecognized command line option "-std=c++11"
> cc1plus: error: unrecognized command line option "-std=c++11"
> cc1plus: error: unrecognized command line option "-std=c++11"
> ...
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On 2015-Mar-12, at 01:24 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> Sorry to top post, but try adding WITH_CLANG=t
>
> Warner
>
>> On Mar 13, 2015, at 4:18 AM, Mark Millard <mar...@dsl-only.net> wrote:
>>
>> Basic context:
>>
>> $ freebsd-version -ku; uname -a
>> 11.0-CURRENT
>> 11.0-CURRENT
>> FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar 9
>> 22:24:27 PDT 2015
>> root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc
>> $ svnlite info
>> Path: .
>> 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: 380683
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: demon
>> Last Changed Rev: 380683
>> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015)
>>
>> I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood UPDATING
>> for the combination of starting from 10.1 on powerpc/powerpc64 and ended up
>> without clang for both powerpc and powerpc64 before I figure that out.
>>
>> While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build when
>> portmaster'd on powerpc64 it does build on powerpc.
>>
>> So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64)
>> 11.0-CURRENT context to attempt a "cross" compile back to powerpc...
>>
>>
>>
>> The problem:
>> (Or is the below attempt a form of abuse of powerpc64-xtoolchain-gcc?)
>> (Remember: no clang exists beforehand.)
>>
>> For...
>>
>> make CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc
>> TARGET=powerpc TARGET_ARCH=powerpc
>>
>> or
>>
>> make CROSS_TOOLCHAIN=powerpc64-gcc buildworld buildkernel
>> KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc
>>
>> Either way the result fails to complete by attempting to use clang-tblgen
>> when it does not exist (yet?):
>>
>>> ...
>>> --------------------------------------------------------------
>>>>>> stage 1.2: bootstrap tools
>>> --------------------------------------------------------------
>>> ...
>>> ===> lib/clang/libllvmx86instprinter (buildincludes)
>>> ===> lib/clang/libllvmx86utils (buildincludes)
>>> ===> lib/clang/include (buildincludes)
>>> clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h
>>> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td
>>> make[6]: exec(clang-tblgen) failed (No such file or directory)
>>> *** Error code 1
>>>
>>> Stop.
>>> make[6]: stopped in /usr/src/lib/clang/include
>>> *** Error code 1
>>>
>>> Stop.
>>> make[5]: stopped in /usr/src/lib/clang
>>> *** Error code 1
>>>
>>> Stop.
>>> make[4]: stopped in /usr/src/lib
>>> *** Error code 1
>>>
>>> Stop.
>>> make[3]: stopped in /usr/src/lib
>>> *** Error code 1
>>>
>>> Stop.
>>> make[2]: stopped in /usr/src
>>> *** Error code 1
>>>
>>> Stop.
>>> make[1]: stopped in /usr/src
>>> *** Error code 1
>>>
>>> Stop.
>>> make: stopped in /usr/src
>>
>>
>>
>> Even if overall this style of bootstrap should not work it seems odd to me
>> that clang-tblgen use was attempted before it was built.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> _______________________________________________
>> freebsd-toolchain@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
>
>
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
