head -r324071 system clang 5 based powerpc64 building ports: x11-toolkit/qt5-gui gets "clang++: error: unknown argument: '-mminimal-toc'"

I attempted a poudriere based build of some ports and the qt5-gui build involved failed with the following sorts of notices. But the context is using the same sources as I've been testing various proposed armv6 related build fixes with (fixes taken from bugzilla activity, not my own). I doubt that

Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [vec_step macro name in gcc7's altivec.h]

Summary of later additions: devel/powerpc64-gcc has the same problem as gcc7 in this clang-based powerpc64. My note about using gcc 4.2.1 for the kernel build was wrong. (My 32-bit powerpc builds are that way, not the powerpc64 ones.) On 2017-Sep-29, at 1:51 AM, Mark Millard wrote: > [Looks

[Bug 218808] www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols (WITH_LLD_IS_LD)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218808 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Fri Sep 29 12:51:15 UTC 2017 New revision: 450890 URL: https://svnweb.freebsd.org/changeset/ports/450890 Log: gecko: unbreak on 12.0

Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [vec_step macro name in gcc7's altivec.h]

[Looks like gcc7 might be causing its own problem via a vec_step macro name in its altivec.h .] On 2017-Sep-29, at 1:14 AM, Mark Millard wrote: > I attempted a poudriere based build of some > ports and the gcc7 build involved failed > with the following sorts of notices: > > >

head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step?

I attempted a poudriere based build of some ports and the gcc7 build involved failed with the following sorts of notices: /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: error: expected unqualified-id tree new_vec, vec_init, vec_step, t; ^

[Bug 222641] www/firefox libgkrust.a: could not read symbols

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222641 --- Comment #8 from Konstantin Belousov --- (In reply to Jan Beich from comment #7) There are a lot of clues in the reports. I am almost sure, that the error message comes out because in-tree ld(1) does not know about