"ldconfig -m <path>" so the order of ldconfig search directories after
package installation is the same as after a reboot. The original command
simply appends the path to the list of directories while the ldconfig rc.d
script uses "sort -u".
Bump lang/gcc* which are known to install libraries with exactly the same
name so the library loaded at runtime depends on the order of the search
directories.
PR: 228046
Approved by: portmgr (antoine)
Since clang++ 6.0.0 now defaults to -std=gnu++14 (similar to g++ 6 and
higher), building gcc48, gcc49 or gcc5 produce quite a number of
"invalid suffix on literal; C++11 requires a space between literal and
identifier" errors. This is because in many places, double quotes are
directly followed by printf helper macros like HOST_WIDE_INT_PRINT.
In gcc 6 and later, spaces were added between the double quotes and the
macros, to fix this issue, but for earlier versions, use a combination
of find, grep and sed to add them mechanically throughout the respective
source trees.
In addition, gcc5 needs a regular patch to fix an incorrect call to
error(), which should have been error_at(). (This was a mismerge by
upstream.)
Approved by: gerald (maintainer)
PR: 224927
MFH: 2018Q1
[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.
