Date: Sun, 24 Apr 2016 07:16:06 -0700 From: Mark Millard <markmi@dsl-only.net> To: Steve Wills <swills@FreeBSD.org> Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? Message-ID: <F7E6ED93-A73D-406D-A7BF-B1B80C61871F@dsl-only.net> In-Reply-To: <571CC2F2.2060601@FreeBSD.org> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Apr-24, at 5:58 AM, Steve Wills <swills@FreeBSD.org> wrote:
>=20
> So lang/gcc6-devel builds fine using gcc49 (which builds fine and =
isn't
> currently marked broken. Can we patch the lang/gcc6-devel port so that
> it uses gcc49 when building on powerpc64?
>=20
> Also, which compiler are you using for building ruby?
>=20
> Steve
For all the port update activity (including ruby) I used gcc49, =
/etc/make.conf being:
# more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20
WRKDIRPREFIX=3D/usr/obj/portswork
WITH_DEBUG=3D
WITH_DEBUG_FILES=3D=20
MALLOC_PRODUCTION=3D
#
#
# For trying gcc49...
#=20
CC=3D/usr/local/bin/gcc49
CXX=3D/usr/local/bin/g++49=20
CPP=3D/usr/local/bin/cpp49
. . . (binutils macros omitted here) . . .
(I do not know if lang/gcc [or lang/gcc48] would work or not. I prefer a =
tool chain with a more modern C++ available but gcc49 is not yet what =
lang/gcc builds.)
I've seen notation like:
USE_GCC=3D 4.9+
in port Makefiles. Also notation like:
.if ${ARCH} =3D=3D powerpc64
and:
.if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64"
So may be the extra notation in the Makefile(s) in question could be =
something like:
# clang 3.8.0 and before is still broken in various ways for powerpc and =
powerpc64:
.if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64"
USE_GCC=3D 4.9+
.endif
I list both powerpc variants because powerpc and powerpc64 both have =
clang problems making buildworld a no-go by default and if gcc 4.2.1 =
rejects a port for one it would normally also reject for the other. =
There may be other ${ARCH} values that would also be appropriate because =
they are also stuck at gcc 4.2.1 .
I do not claim to know necessary vs. sufficient status: more might be =
needed for some configurations (rpath issues? mixture of libraries =
compiled by distinct gcc's?). But I expect that the above should be =
better than being marked broken.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Older material:
On 04/24/16 03:19 AM, Mark Millard wrote:
> [A top-post of the results of my test build of lang/gcc6-devel using =
gcc49 to do the build (until it switches over to xgcc). I do not have =
lang/gcc or lang/gcc48 installed.]
>=20
> lang/gcc6-devel's update built fine in my =
powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a =
powerpc64 PowerMac. The options were as I normally use:
>=20
>> # more /var/db/ports/lang_gcc6-devel/options
>> # This file is auto-generated by 'make config'.
>> # Options for gcc6-devel-6.0.0.s20160110
>> _OPTIONS_READ=3Dgcc6-devel-6.0.0.s20160110
>> _FILE_COMPLETE_OPTIONS_LIST=3DBOOTSTRAP GRAPHITE JAVA MULTILIB
>> OPTIONS_FILE_UNSET+=3DBOOTSTRAP
>> OPTIONS_FILE_UNSET+=3DGRAPHITE
>> OPTIONS_FILE_UNSET+=3DJAVA
>> OPTIONS_FILE_UNSET+=3DMULTILIB
>=20
>=20
> I will note that ruby is implicitly in use in my environment and it =
too had been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , =
and lang/ruby23 all were so marked. (So I commented those marks out.)
>=20
> My build that upgraded from ruby21 to ruby22 went fine.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> On 2016-Apr-23, at 5:21 PM, Mark Millard <markmi@dsl-only.net> wrote:
>>=20
>> On 2016-Apr-23, at 4:17 PM, Steve Wills <swills@FreeBSD.org> wrote:
>>>=20
>>> Hi,
>>>=20
>>> On 04/23/16 05:50 PM, Mark Millard wrote:
>>>> Recently a large block of ports (including lang/gcc6-devel) were
>>>> marked in their Makefiles with
>>>>=20
>>>>> BROKEN_powerpc64=3D Does not build
>>>>=20
>>>>=20
>>>> Does this only apply for use of gcc/g++ 4.2.1 or specific other
>>>> verions? If so that is not the only way to have a powerpc64
>>>> environment. For example: how "official" is use of
>>>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
>>>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)?=20
>>>=20
>>>=20
>>> The intent was just that they don't build with the default config, =
ie,
>>> gcc 4.2.1 from base. If there are ways to make things build with =
other
>>> compilers, we should look at getting those changes into ports.
>>>=20
>>> You can find the logs of the build that I based all those changes on =
here:
>>>=20
>>> =
http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower=
pc-default&build=3D2016-04-02_20h57m16s
>>>=20
>>> Specifically the gcc6-devel one is here:
>>>=20
>>> =
http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-=
02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log
>>>=20
>>> Though I realize now that was simply a timeout and perhaps shouldn't
>>> have been marked as broken. A few of the llvm ones timed out and I
>>> didn't mark those as broken and meant to not mark any that timed out =
as
>>> broken, and to go back and retry them, but didn't notice this one =
was a
>>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if =
it
>>> builds for you.
>>=20
>> Since my original note -r413919 has updated devel/gcc6-devel. So I'll =
end up testing that update once I get to that point.
>>=20
>> I'll note that the svn-ports-head entry for -r412746 lists several =
llvm items:
>>=20
>> head/devel/llvm-cheri/Makefile
>> head/devel/llvm-devel/Makefile
>> head/devel/llvm33/Makefile
>> head/devel/llvm34/Makefile
>> head/devel/llvm38/Makefile
>>=20
>> But I do not build any of those normally. llvm38 likely is toolchain =
vintage dependent for if it builds or not. Others may be as well.
>>=20
>>> Also note that build was using the 2016Q2 branch, but the
>>> BROKEN_powerpc64 was committed to the main branch. Perhaps that =
change
>>> should be merged to the 2016Q2 branch.
>>>=20
>>> Anyway, I'm currently retrying the build, after fixing pixman and
>>> merging that to the 2016Q2 and then locally patching in the
>>> BROKEN_powerpc64 things into my local tree. You can see the progress =
of
>>> that here:
>>>=20
>>> =
http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower=
pc-default&build=3D2016-04-21_17h38m55s
>>>=20
>>>=20
>>>> Can broken be marked for only specific tool chains?
>>>>=20
>>>=20
>>> Not trivially, but it's probably doable somehow.
>>>=20
>>>>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU=20
>>>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M:
>>>>> Sat Apr 9 22:22:19 PDT 2016
>>>>> =
root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v=
tsc-NODEBUG
>>>>> powerpc 1100105 1100105
>>>>=20
>>>> For the rest of this note I'll focus on lang/gcc-devel since I =
happen
>>>> to build and install it.
>>>>=20
>>>>> # pkg info '*gcc*' gcc49-4.9.4.s20160406=20
>>>>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0=20
>>>>> powerpc64-xtoolchain-gcc-0.1
>>>>=20
>>>> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on =
the
>>>> that same old PowerMac. -r413188 is the prior lang/gcc-devel check =
in
>>>> before being marked broken for powerpc64. For how I build it was =
not
>>>> broken at the time.
>>>>=20
>>>> I historically use devel/powerpc64-xtoolchain-gcc (so
>>>> devel/powerpc64-gcc as well) for the so-called "cross build" stages
>>>> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross
>>>> builds for TARGET_ARCH=3Dpowerpc64 from an amd64 context =
sometimes.)
>>>>=20
>>>> gcc 4.2.1 is not present before, during, or after on the old
>>>> PowerMac. I do build clang and various related materials but do not
>>>> use clang for buildworld/buildkernel related activity. I experiment
>>>> with using clang for other things at times.
>>>>=20
>>>> I historically use lang/gcc49 on the old PowerMac for:
>>>>=20
>>>> A) building devel/powerpc64-gcc (not the only way to try to build
>>>> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) =
C)
>>>> building lang/gcc6-devel (not the only way to try to build it)
>>>>=20
>>>> [I do not have lang/gcc5 built/installed only because it and
>>>> devel/powerpc64-gcc have file conflicts when they are based on the
>>>> same gcc version. Getting devel/powerpc64-gcc to build and install =
on
>>>> a powerpc64 requires some workarounds because it is not a true =
cross
>>>> compile environment and some file names are odd for self-hosted and
>>>> so not found during staging's copy activities.]
>>>>=20
>>>> [I do build the system's clang 3.8.0 but do not use it other than =
for
>>>> exploring/checking its current powerpc64 FreeBSD limitations. It =
does
>>>> work for various things but not everything. Those experiments do =
not
>>>> include buildworld or buildkernel. For example: clang 3.8.0 =
targeting
>>>> powerpc64 can not build libstand due to lack of software floating
>>>> point support. C++ exception handling built via clang for powerpc64
>>>> is messed up as well.]
>>>>=20
>>>>=20
>>>=20
>>> It would be nice if we could fix those things and get powerpc(64) =
built
>>> with clang.
>>=20
>> https://llvm.org/bugs/show_bug.cgi?id=3D25780 [a meta-list of reports =
that block use by freebsd] lists various powerpc and powerpc64 =
code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each =
of the following includes examples of powerpc64 code-generation issues, =
not just powerpc (non-64) ones.
>>=20
>> https://llvm.org/bugs/show_bug.cgi?id=3D26970
>> https://llvm.org/bugs/show_bug.cgi?id=3D26856
>> https://llvm.org/bugs/show_bug.cgi?id=3D26844
>> https://llvm.org/bugs/show_bug.cgi?id=3D26761
>>=20
>> (I also submitted reports to freebsd as well so there would be =
reminders to track clang fixes if they ever occur. There may be more =
issues than I reported in either place.)
>>=20
>> As I remember I thought there were also some FreeBSD problems that =
would be present after the above were fixed but the code generation =
problems made it harder to be sure. Even if I was correct any testing =
based on the bad code-generation by clang in overlapping areas would not =
work. I'd prefer to recheck/reanalyze based on seeing good code =
generation results.
>>=20
>> Unfortunately while I can slowly analyze/research the code generated =
it would take a lot longer to get the point of doing non-trival work on =
llvm or clang itself. And since somewhat after clang 3.8.0 moved into =
11.0-CURRENT other things have kept me mostly out of clang =
investigations. I've just been rebuilding FreeBSD and some ports =
periodically in order to avoid large jumps later.
>>=20
>>=20
>>>>=20
>>>> I have started a powerpc64 self-hosted buildworld/buildkernel for =
an
>>>> update to 11.0-CURRENT -r298518 in preparation for then updating my
>>>> ports to -r413907 or so.
>>>>=20
>>>> My intent is to comment out the BROKEN_powerpc64 line in
>>>> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still =
(re-)builds
>>>> once everything else is up to date.
>>>>=20
>>>> But the builds involved take many hours so I'll likely not have a
>>>> result to report until tomorrow (or later).
>>>>=20
>>>>=20
>>>> Supporting example details:
>>>>=20
>>>>> # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path:
>>>>> /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head=20
>>>>> Relative URL: ^/head Repository Root:
>>>>> https://svn0.us-west.freebsd.org/ports Repository UUID:
>>>>> 35697150-7ecd-e111-bb59-0022644237b5 Revision: 413230 Node Kind:
>>>>> directory Schedule: normal Last Changed Author: kmoore Last =
Changed
>>>>> Rev: 413230 Last Changed Date: 2016-04-13 13:07:37 -0700 (Wed, 13
>>>>> Apr 2016)
>>>>=20
>>>> (I'll svnlite update -r413907 /usr/ports [or there about] after the
>>>> system is updated. The above was used for my existing =
lang/gcc-devel
>>>> build on powerpc64 for powerpc64.)
>>>>=20
>>>>> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20
>>>>> WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D=20=
>>>>> MALLOC_PRODUCTION=3D # # # For trying gcc49... #=20
>>>>> CC=3D/usr/local/bin/gcc49 CXX=3D/usr/local/bin/g++49=20
>>>>> CPP=3D/usr/local/bin/cpp49 # # # For trying port binutils... #=20
>>>>> =
CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/
>>>>>=20
>>>>>=20
>>> AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as
>>>>> AR=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar=20
>>>>> LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld=20
>>>>> NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm=20
>>>>> OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy=20
>>>>> OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump=20
>>>>> RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib=20
>>>>> SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size #NO-SUCH:
>>>>> STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings=20
>>>>> STRINGS=3D/usr/local/bin/strings
>>>>=20
>>>> The above sort of make.conf is used for port builds, though I may
>>>> edit the details to control my experiments.
>>>>=20
>>>> The below are tied to buildworld/buildkernel related activity:
>>>>=20
>>>>> # more
>>>>> =
/root/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_cla=
ng_xtoolchain-powerpc64-host.sh
>>>>> script
>>>>> =
/root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto=
olchain-powerpc64-host-$(date
>>>>> +%Y-%m-%d:%H:%M:%S) \ env =
__MAKE_CONF=3D"/root/src.configs/make.conf"
>>>>> =
SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-=
host"
>>>>> \ MAKEOBJDIRPREFIX=3D"/usr/obj/xtoolchain/powerpc.powerpc64" \ =
make
>>>>> $*
>>>>=20
>>>>=20
>>>> /root/src.configs/make.conf (used for buildworld/buildkernel) is
>>>> normally empty.
>>>>=20
>>>>> # more
>>>>> /root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20
>>>>> TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3Dpowerpc64=
=20
>>>>> TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D11.0 #=20
>>>>> KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3Dpowerpc .if =
${.MAKE.LEVEL} =3D=3D
>>>>> 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif #=20
>>>>> WITHOUT_CROSS_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D=20
>>>>> #WITH_LIB32=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D=20=
>>>>> WITH_LLDB=3D # # LIB32 builds but does not work via gcc variants
>>>>> [crtbeginS code problem(s)] WITHOUT_LIB32=3D WITHOUT_GCC=3D=20
>>>>> WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D #=20
>>>>> WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . =
#
>>>>> So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . =
#
>>>>> TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related =
bintutils.
>>>>> . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc=20
>>>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ =
.if
>>>>> ${.MAKE.LEVEL} =3D=3D 0=20
>>>>> =
XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc=
c
>>>>>=20
>>>>>=20
>>> =
XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g=
++
>>>>> =
XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c=
pp
>>>>>=20
>>>>>=20
>>> .export XCC
>>>>> .export XCXX .export XCPP=20
>>>>> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as=20
>>>>> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar=20
>>>>> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld=20
>>>>> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm=20
>>>>> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy=20
>>>>> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump=20
>>>>> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib=20
>>>>> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH:
>>>>> XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings=20
>>>>> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export
>>>>> XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export
>>>>> XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # #=20=
>>>>> # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but =
not
>>>>> xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if
>>>>> ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include
>>>>> /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv =
C_INCLUDE_PATH=3D/usr/include
>>>>> CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49
>>>>> -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 =
.export
>>>>> CC .export CXX .export CPP=20
>>>>> =
AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a=
s
>>>>>=20
>>>>>=20
>>> =
AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a=
r
>>>>> =
LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l=
d
>>>>>=20
>>>>>=20
>>> =
NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n=
m
>>>>> =
OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/objcopy
>>>>>=20
>>>>>=20
>>> =
OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/objdump
>>>>> =
RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b=
in/ranlib
>>>>>=20
>>>>>=20
>>> =
SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin=
/size
>>>>> #NO-SUCH:
>>>>> =
STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/strings
>>>>>=20
>>>>>=20
>>> STRINGS=3D/usr/local/bin/strings
>>>>> .export AS .export AR .export LD .export NM .export OBJCOPY =
.export
>>>>> OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif
>>>>=20
>>>>> # svnlite status /usr/src ? /usr/src/.snap M
>>>>> =
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
>>>>>=20
>>>>>=20
>>> M /usr/src/lib/csu/powerpc64/Makefile
>>>>> ? /usr/src/restoresymtable ?
>>>>> /usr/src/sys/arm/conf/RPI2-NODBG M
>>>>> /usr/src/sys/boot/ofw/Makefile.inc M
>>>>> /usr/src/sys/boot/powerpc/Makefile M
>>>>> /usr/src/sys/boot/powerpc/Makefile.inc M
>>>>> /usr/src/sys/boot/uboot/Makefile.inc M
>>>>> /usr/src/sys/conf/Makefile.powerpc M
>>>>> /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ?
>>>>> /usr/src/sys/powerpc/conf/GENERIC64-NODBG ?
>>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc ?
>>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ?
>>>>> /usr/src/sys/powerpc/conf/GENERICvtsc ?
>>>>> /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG M
>>>>> /usr/src/sys/powerpc/ofw/ofw_machdep.c M
>>>>> /usr/src/sys/powerpc/powerpc/exec_machdep.c
>>>>=20
>>>>=20
>>>=20
>>> Let me know what you find. There was some work on external compiler
>>> support, though I don't know it's current status.
>>=20
>> My powerpc64 FreeBSD activity is completely dependent on the external =
compiler support: I'm using FreeBSD's modern libc++, not libstdc++. But =
there are some workarounds involved for my complete avoidance of gcc =
4.2.1. I've a few other work arounds for the PowerMac context as well. =
For example: downloaded release and snapshot installations do not =
reliably boot such PowerMacs but instead frequently hang during boot. =
(The frequency may depend on the amount of RAM.)
>>=20
>> I'll let you know how the updated devel/gcc6-devel goes for my style =
of powerpc64 environment.
>>=20
>> If a devel/gcc6 appears I'll likely build it at some point.
>>=20
>>> Steve
>>=20
>> =3D=3D=3D
>> Mark Millard
>> markmi at dsl-only.net
>>=20
>>=20
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to =
"freebsd-ports-unsubscribe@freebsd.org"
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7E6ED93-A73D-406D-A7BF-B1B80C61871F>