devel/*{-xtoolchain,}-gcc: Retire the old GCC external toolchain ports.
These have been supplanted by the devel/freebsd-gcc6 port which uses
separate flavors for each target architecture and bundles the
CROSS_TOOLCHAIN makefile.
Feedback from: jrm
Reviewed by: lwhsu, bapt
Differential Revision: https://reviews.freebsd.org/D30765
Cleanup packing lists for xtoolchain gcc packages.
- Add missing entries for gcov-dump and the gcov-tool manpage to the
various xtoolchain gcc ports.
- Add gcov-dump to the post-install loops that handle optional renaming
of tools and manpages.
Reviewed by: kan
Differential Revision: https://reviews.freebsd.org/D16465
Upgrade ext-toolchain GCC ports to GCC 6.4.0
This is the latest supported release in GCC 6.x series.
Drop aarch64 support patch - it has been committed upstream.
Enable ifunc suppport by default.
PR: 228161
Reviewed by: bapt (update part)
Differential Revision: https://reviews.freebsd.org/D13602
Fix --sysroot for cross-toolchain GCC packages
By default, GCC assumes that a cross compiler should not have any valid
initial include or library paths aside from /usr/local/lib/gcc/<mumble>/.
This means that one cannot use --sysroot to point to a system root for
another architecture and have GCC automatically look for headers in
${sysroot}/usr/include, etc. Currently we workaround this in FreeBSD's
build system with explicit -isystem, -B, and -L directives. However,
this is cumbersome compared to clang (where a bare --sysroot DTRT)
especially when using the compiler to build other software (such as test
programs, etc.).
One can override GCC's assumption and force it to assume that it should
honor --sysroot by setting the '--with-sysroot' option to force GCC to
assume a specific system root. By setting this to '/', this means that
(Only the first 15 lines of the commit message are shown above )
Mark the gcc crosscompiler ports as broken on various tier-2 archs.
Unfortunately neither the maintainer or I have time at the moment
to chase down all of these failures. The "fails to package" ones
ought to be fairly easy to fix.
Discussed with: maintainer
Add mips/mips64 cross compile toolchains.
This is all kan's work; I've just verified that it spat out working
binaries and (at least) working 32 bit kernels.
Reviewed by: bapt
Obtained from: kan