Skip site navigation (1)Skip section navigation (2)
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>