[1] Make sure what we install is stripped (i.e., debug info is removed).
(For more background see revisions 454177 and 454422.)
[2] Add a patch that we pulled into gcc6-devel via upstream a week ago
that addresses a real-world issue around threading and unwinding as
files/patch-freebsd-unwind.h .
Bump PORTREVISION since [2] is a functional change and [1] changes the
package.
Reported by: Ports QA Framework, miwi, sobomax [1]
Discussed with: tijl, miwi [1]
Tested by: sobomax [1]
Differential Revision: https://reviews.freebsd.org/D10357 [1]
Make sure what we install is stripped (i.e., debug info is removed).
The straightforward way is setting INSTALL_TARGET to install-strip,
which is supported by the upstream GCC build machinery.
Unfortunately this fails when running as regular user (non-root)
since strip requires write permission to the files in question,
and we install binaries as r-xr-xr-x by default. To work around
that we need to set BINMODE to allow for write access by the user,
something that's common on GNU/Linux (which is why this probably
has not been noticed there). This is not necessary when running
as root.
(A different approach suggested was to set STRIP=true, alas that
leads to many files actually not being stripped. This is due to
GCC using its own script install-sh that in turn uses cp, chmod,
strip,... instead of our own install-* tools in many cases.)
According to tests by sobomax@ and me installs of lang/gcc6 went
down by about a fourth.
Do not bump PORTREVISION since this only changes builds by non-root
users, is not a functional change, and the previous state of using
a bit more storage had been there "forever".
Reported by: Ports QA Framework, miwi, sobomax
Discussed with: tijl, miwi
Tested by: sobomax
Differential Revision: https://reviews.freebsd.org/D10357
This adds a man page for gcov-dump5 (introduced recently) and also
one for gcov-tool5 (which we have had for a while).
and 436904
This brings a new little utility program gcov-dump6 to dump code
coverage data (unfortunately without a man page or documentation).
from lang/gcc5-devel into pkg-plist which I had missed in the update
to GCC 5.5 a few minutes ago.
fixes compared to GCC 5.4 and is the last release planned on the GCC 5
branch which is now closed.
files/patch-aarch64-support, files/patch-disable-armvhf-config.gcc,
files/patch-libgcc-config-arm-unwind-arm, and files/patch-x86-64-fix-m16
all have been merged upstream in between GCC 5.4 and 5.5 and can thus
be removed; the same is the case for most of files/patch-libc++.
Finally, the tarball is now compressed using xz instead of bzip2.
PR: 216266
by default (and guarded by the GRAPHITE option).
Now that we have both GCC 6 and GCC 7 in the tree and GCC 5 is going end
of live upstream soon, remove Graphite support from the GCC 5-related
ports. Anyone using Graphite is better served by the newer versions of
GCC.
port), remove Java support (incl. the JAVA option) from lang/gcc5. Only
one other port actually relies on this and this change speeds up the build
and reduces the size of this port/package quite a bit.
some commented (and thus disabled) logic around this on the way.
This brings the active lang/gcc* release-based ports in sync with
their respective lang/gcc*-devel twins.
PR: 221905 [1]
Submitted by: linimon [1]
installation / packaging to avoid breakage when FreeBSD's headers are
changing afterwards. Several fellow committers have strongly indicated
that our headers do not need the kind of adjustments that GCC performs.
for arm*-*-freebsd*.
This patch is already pushed upstream to all active gcc branches.
GCC-5, GCC-6, GCC-7 and trunk. The gcc?-devel ports will catch up these bits
with the next update.
Once a new release for gcc6 or gcc5 is done, this patch will be obsolete.
Approved by: gerald@ (maintainer)
Collection (requested by USE_GCC=yes and various USES=compiler
invocations) from GCC 4.9.4 to GCC 5.4.
files/patch-arm-support and files/patch-gcc_system.h have become
obsolete. New patches files/patch-arm-unwind-cxx-support and
files/patch-libc++ help support arm targets and new libc++ in base.
ONLY_FOR_ARCHS now also includes arm.
A new option GRAPHITE_DESC, off by default for now, adds support for
Graphite loop optimizations.
Finally, conflicts with other lang/gcc* ports are adjusted suitably.
In terms of changes for users, this upgrade brings the following:
The default mode for C is now -std=gnu11 instead of -std=gnu89.
New warning options -Wc90-c99-compat and -Wc99-c11-compat may
prove useful on that front.
The C++ front end now has full C++14 language support including
C++14 variable templates, C++14 aggregates with non-static data
member initializers, C++14 extended constexpr, and more.
The Standard C++ Library (libstdc++) has full C++11 support and
experimental full C++14 support. It uses a new ABI by default.
There have been significant improvements to inter-procedural optimizations
and link-time optimization such as One Definition Rule based merging of C++
types as well as register allocation.
OpenMP 4.0 specification offloading features are now supported by the C,
C++, and Fortran compilers. Cilk Plus, an extension to the C and C++
languages to support data and task parallelism, has been added as well.
New warning options -Wswitch-bool, -Wlogical-not-parentheses,
-Wbool-compare and -Wsizeof-array-argument may prove useful as
may new preprocessor directives __has_include, __has_include_next,
and __has_attribute.
GCC can now be built as a shared library for embedding in other processes
(such as interpreters), suitable for Just-In-Time compilation to machine
code. This provides a C API and a C++ wrapper API.
Many code generation improvements for AArch64, ARM, support for
AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
improvements on many targets.
The Local Register Allocator (LRA) now contains a rematerialization
subpass and is able to reuse the PIC hard register on x86/x86-64 to
improve performance of position independent code.
https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
overview of issue you may encountering porting to this new version.
PR: 216707, 218125
Tested by: antoine (-exp runs)
Supported by: jbeich, tcberner, and others
Remove files/patch-unwind-ia64.h: we have not been supporting ia64 with
this release series, i.e., ONLY_FOR_ARCHS does not include ia64.
No PORTREVISION bump since nothing should actually change for
existing/supported platforms.
Reported by: andreast [1]
libc++, because it attempts to redefine abort():
In file included from /wrkdirs/usr/ports/lang/gcc5/work/gcc-5.4.0/gcc/auto-profile.c:25:
In file included from /usr/include/c++/v1/map:446:
/usr/include/c++/v1/functional:1398:2: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~~~~~
/usr/include/c++/v1/__config:383:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
Patch this in the same way as the other gcc ports, by including <new> in
gcc/system.h, and moving a few includes to before "system.h".
Approved by: gerald (maintainer)
PR: 216266
MFH: 2017Q1
locale set by the user. Add LANG=C and LC_ALL=C at the beginning of
bsd.port.mk and export them so all commands are executed with the C locale.
LC_ALL=C overrides all other LC_* variables. LANG is used by setlocale(3)
as default value for LC_* variables, so normally it isn't used when LC_ALL
is set, but there's code out there that looks at LANG directly so it's safer
to set it as well. The only commands not captured by this are !=
assignments before any inclusion of bsd.port.*mk.
Introduce USE_LOCALE=<locale> that adds LANG=<locale> and LC_ALL=<locale> to
CONFIGURE_ENV and MAKE_ENV so upstream build systems can be executed with a
different locale (e.g. USE_LOCALE=en_US.UTF-8).
PR: 215882
Exp-run by: antoine
Approved by: portmgr (antoine)
GCC can be mis-built, leading to an internal compiler error building
libgcc/libgcov.c, at least on FreeBSD 11.
Adjust OPTIONS_DEFINE_powerpc64 and OPTIONS_DEFAULT_powerpc64
incrementally (with +=) to avoid overwriting settings defined
at the top of the Makefile (or child ports). [1]
Submitted by: swills [1]
Reported by: swills
Only override CONFIGURE_TARGET for amd64 which is x86-64/x86_64 for the
rest of the world including GNU and GCC. For all other architectures
it already defaults to the value we were setting.
GCC uses an AWK script to generate source code that helps process
command-line options. According to POSIX, string comparisons (and
hence sorting) are to be performed based on the locale's collating
order. Alas GNU AWK only does so in POSIX mode, whereas starting
with FreeBSD 11 we do so by default, running into a bug (or false
assumption) with that script used by GCC.
Setting MAKE_ARGS such that AWK is always invoked in the C locale
works around this bug.
PR: 210122, 211742
Submitted by: jkim
files/patch-build-without-bootstrap and files/patch-gcc-freebsd-powerpc64
(ELFv2 support for FreeBSD PowerPC64) are now upstream, so drop them.
Due to timeing of the release freeze files/patch-armv6-hf-support has not
been integrated in this upstream release yet.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. This change is the second attempt at doing this: the
first attempt went in r401072 and was reverted in r401074 because the diff
was bogus and enabled the new MULTILIB option under all platforms instead
of just powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
I'm not sure what happened exactly but I think I committed the change from
the wrong client. The applied change enabled the MULTILIB option for all
architectures and not only powerpc64. Let's just revert the commit and do
it properly from scratch; other things might be wrong so I wanna take a
closer look, and it's best to just revert quickly.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. Waited a week to ensure the change caused nothing to go
horribly wrong but this change is very low risk because it only affects
powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
