Date: Thu, 19 Mar 2015 02:26:35 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Subject: Re: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant Message-ID: <0273C21A-C8BD-4D67-9A2B-E4C9938148AF@dsl-only.net> In-Reply-To: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> References: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
After the previously described buildworld/buildkernel sequence:
installkernel then shutdown -r now and so-far-so-good after the reboot
installworld then shutdown -r now and so-far-so-good after the reboot
delete-old and delete-libs then shutdown -r now and still good after the =
reboot
$ dmesg -a | 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
...
Of course this is in part based on prior boot1.elf establishment on the =
media (WITHOUT_BOOT=3D) and it lacks lib32 (WITHOUT_LIB32=3D) --at least =
once I had delete-old and delete-old-libs delete things.
(The delete-old and delete-old-libs may have made doing another =
buildworld buildkernel a mess since I did not set up for keeping gcc =
4.2.1 related things as active generally. libstdc++ is gone, for =
example. I'm not sure legacy will build without libstdc++ and libstdc++ =
may well not be automatically regenerated. But I wanted to check on the =
lack of old context still being okay for booting and basic operation. I =
can always go back and duplicate my paranoia-copy from just before =
installkernel.)
Also I forgot to mention in the oddities section: establishing libcxxrt =
and libc++...
I needed to get libcxxrt and libc++ in place before buildworld =
buildkernel but after powerpc64-xtoolchain-gcc was installed, using a =
context something like...
> # 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
> #CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1
> #LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++
> NO_WERROR=3D
If I remember right a summary would be...
cd /usr/srcC/lib/libcxxrt/; make; make install
cd /usr/srcC/lib/libc++/; make; make install
in that order.
These are what established some context for using
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1
> LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++
in /etc/src.conf during buildworld/buildkernel, unless I misremembering =
something.
Now that the rebuilds are installed and running the appropriate paths =
are different:
> CXXFLAGS+=3D-I/usr/include/c++/v1
> LDADD+=3D-L/usr/lib -lc++
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2015-Mar-18, at 09:28 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
Basic starting context:
> # freebsd-version -ku; uname -apKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed =
Mar 11 19:23:14 PDT 2015 =
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU=
G powerpc powerpc64 1100062 1100062
No clang present to start with: I did delete-old at the end of the =
10.1-STABLE -> 11.0-CURRENT upgrade before realizing I'd end up with no =
clang at all and no direct way to build it.
No initial clang means no initial C++11 library either. (Beyond gcc =
4.2.1's range of coverage.)
I have a PowerMac G5 specific change to make booting reliable and some =
changes for getting information from early boot failures in case I get =
any more of them. So it is not a strict -r279514 build.
So for CROSS_TOOLCHAIN=3Dpowerpc64-gcc how much was I able to include in =
buildworld buildkernel (I've not tried including gcc yet)? Well doing...
> make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \
> WITHOUT_LLDB=3D \
> WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \
> WITHOUT_BOOT=3D WITHOUT_LIB32=3D \
> buildworld buildkernel \
> KERNCONF=3DGENERIC64vtsc-NODEBUG \
> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64
using the context...
> # 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
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1
> LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++
> NO_WERROR=3D
completed buildworld buildkernel.
I have not tried installkernel nor installworld yet. WITH_BOOT=3D and =
WITH_LIB32=3D materials would be missing or come from other types of =
builds that I've done.
Unfortunately there is more to getting the above to work then just the =
above. Also the below includes notes about why various things are as =
they are above.
Various oddities need to be avoided/sidestepped for =
CROSS_TOOLCHAIN=3Dpowerpc64-gcc use...
The first oddity is that on a powerpc64 11.0-CURRENT =
powerpc64-xtoolchain-gcc fails to complete its installation because =
powerpc64-gcc fails to complete its installation. The powerpc64-gcc =
installation problems do not happen on powerpc (non-64) 11.0-CURRENT but =
do happen on powerpc64, suggesting TARGET !=3D TARGET_ARCH handling =
issues for the port. 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.
buildworld attempts to use clang's then-non-existent table generation =
programs if WITH_CLANG=3D was used: So I used...
WITHOUT_CLANG_BOOTSTRAP=3D
WITHOUT_CLANG=3D
WITHOUT_LLDB=3D
"-m elf32pcc_fbsd" and -melf32pcc_fbsd were not supported on the command =
line for powerpc64-gcc: I did not try to change things so that gcc 4.2.1 =
would be used just for WITH_LIB32=3D and WITH_BOOT=3D. I was just trying =
to figure what and how I can use powerpc64-xtools --and where I can not =
currently do so. So I used...
WITHOUT_BOOT=3D
WITHOUT_LIB32=3D
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.
I needed to have head's lib/libnv/test/dnv_tests.cc and =
lib/libnv/test/nv_tests.cc from -r279760 or later in order to remove =
ambiguous overload issues.
> make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \
> WITHOUT_LLDB=3D \
> WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \
> WITHOUT_BOOT=3D WITHOUT_LIB32=3D \
> buildworld buildkernel \
> KERNCONF=3DGENERIC64vtsc-NODEBUG \
> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64
When CROSS_TOOLCHAIN=3D..., XCC=3D..., XCXX=3D..., XCPP=3D... are in use =
various build stages do not use those but instead use the original =
CC=3D..., CXX=3D..., CPP=3D... (legacy, bootstrap-tools, build-tools, =
cross-tools, kernel-tools, lib32's build-tools). So I used /etc/src.conf =
to force those last 3 assignments to globally be the same as the X... =
assignments that CROSS_TOOLCHAIN=3Dpowerpc64-gcc uses:
> # 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
> CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1
> LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++
> NO_WERROR=3D
and I listed the other two assignments that =
CROSS_TOOLCHAIN=3Dpowerpc64-gcc picks up. (I do not know that it was =
necessary to do so.)
Looking up the libc++ headers and library did not work automatically so =
I added the CXXFLAGS+=3D... and LDADD+=3D... into /etc/src.conf as =
indicated above. If there had been a LDADDCXX available I would have =
used it instead of LDADD.
NO_WERROR=3D was used to avoid stopping at various warnings.
I choose to use:
WITHOUT_GCC_BOOTSTRAP=3D
WITHOUT_GCC=3D
but there was no specific problem that prompted me to do that. I do not =
yet know how well it would work if gcc was built.
Other points learned in the process...
As noted above "-m elf32ppc_fbsd" was not allowed by powerpc64-gcc (gcc =
4.9.1): it may not allow the space for -m in general. So I tied the =
below but they were also rejected (in a different way)... (I only used =
elf32ppc_fbsd contexts.)
> # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more
> Index: /usr/srcC/Makefile.inc1
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/Makefile.inc1 (revision 279514)
> +++ /usr/srcC/Makefile.inc1 (working copy)
> @@ -396,7 +396,7 @@
> MACHINE_CPU=3D"i686 mmx sse sse2"
> LIB32WMAKEFLAGS=3D \
> AS=3D"${AS} --32" \
> - LD=3D"${LD} -m elf_i386_fbsd -Y =
P,${LIB32TMP}/usr/lib32"
> + LD=3D"${LD} -melf_i386_fbsd -Y =
P,${LIB32TMP}/usr/lib32"
>=20
> .elif ${TARGET_ARCH} =3D=3D "powerpc64"
> .if empty(TARGET_CPUTYPE)
> @@ -406,7 +406,7 @@
> .endif
> LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc
> LIB32WMAKEFLAGS=3D \
> - LD=3D"${LD} -m elf32ppc_fbsd"
> + LD=3D"${LD} -melf32ppc_fbsd"
> .endif
>=20
>=20
> Index: /usr/srcC/sys/boot/i386/Makefile.inc
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/sys/boot/i386/Makefile.inc (revision 279514)
> +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy)
> @@ -14,7 +14,7 @@
> CFLAGS+=3D -m32
> ACFLAGS+=3D -m32
> # LD_FLAGS is passed directly to ${LD}, not via ${CC}:
> -LD_FLAGS+=3D -m elf_i386_fbsd
> +LD_FLAGS+=3D -melf_i386_fbsd
> AFLAGS+=3D --32
> .endif
>=20
> Index: /usr/srcC/sys/boot/ofw/Makefile.inc
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/sys/boot/ofw/Makefile.inc (revision 279514)
> +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy)
> @@ -2,7 +2,7 @@
>=20
> .if ${MACHINE_ARCH} =3D=3D "powerpc64"
> CFLAGS+=3D -m32 -mcpu=3Dpowerpc
> -LDFLAGS+=3D -m elf32ppc_fbsd
> +LDFLAGS+=3D -melf32ppc_fbsd
> .endif
>=20
> .include "../Makefile.inc"
> Index: /usr/srcC/sys/boot/powerpc/Makefile.inc
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/sys/boot/powerpc/Makefile.inc (revision 279514)
> +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy)
> @@ -2,7 +2,7 @@
>=20
> .if ${MACHINE_ARCH} =3D=3D "powerpc64"
> CFLAGS+=3D -m32 -mcpu=3Dpowerpc
> -LDFLAGS+=3D -m elf32ppc_fbsd
> +LDFLAGS+=3D -melf32ppc_fbsd
> .endif
>=20
> .include "../Makefile.inc"
> Index: /usr/srcC/sys/boot/uboot/Makefile.inc
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/sys/boot/uboot/Makefile.inc (revision 279514)
> +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy)
> @@ -2,7 +2,7 @@
>=20
> .if ${MACHINE_ARCH} =3D=3D "powerpc64"
> CFLAGS+=3D -m32 -mcpu=3Dpowerpc
> -LDFLAGS+=3D -m elf32ppc_fbsd
> +LDFLAGS+=3D -melf32ppc_fbsd
> .endif
>=20
> .include "../Makefile.inc"
I did experiment with compiles of clang some and one thing that I =
discovered was:
The following file needed to be updated to be language compliant:
> # svnlite diff =
/usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h
> Index: /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h =
(revision 279514)
> +++ /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h =
(working copy)
> @@ -155,7 +155,7 @@
>=20
> template <class X>
> IntrusiveRefCntPtr(IntrusiveRefCntPtr<X>&& S) : Obj(S.get()) {
> - S.Obj =3D 0;
> + S.Obj =3D 0; /* access to private member needs friendship */
> }
>=20
> template <class X>
> @@ -197,6 +197,10 @@
> private:
> void retain() { if (Obj) IntrusiveRefCntPtrInfo<T>::retain(Obj); }
> void release() { if (Obj) IntrusiveRefCntPtrInfo<T>::release(Obj); =
}
> +
> +/* FIX for Obj private access issue */
> + template<typename X>
> + friend class IntrusiveRefCntPtr;
> };
>=20
> template<class T, class U>
Upstream llvm has this sort of change already, not with the comments.
Other context details:
My list of what files are different than svn is:
# 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
But IntrusiveRefCntPtr.h does not matter if clang building is not =
involved.
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 than the rest of the unmodified source code, teh rest being =
from...
# svnlite info /usr/srcC/
Path: .
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)
# more /etc/make.conf
#CPP=3D/usr/local/bin/clang-cpp36
#CC=3D/usr/local/bin/clang36
#CXX=3D/usr/local/bin/clang++36
WRKDIRPREFIX=3D/usr/obj/portswork
#WITH_DEBUG=3D
MALLOC_PRODUCTION=3D
=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?0273C21A-C8BD-4D67-9A2B-E4C9938148AF>