On the way forward port r499061 | gerald | 2019-04-15 from lang/gcc8 [1]:
GCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
PR: 208120 [1]
Submitted by: tijl [1]
compile and execute 32-bit binaries with gcc.
The gcc part will be upstreamed as soon as gcc trunk opens for new commits.
On the release front, gcc8, we will merge this commit after a week or so.
Approved by: gerald@
No longer require a not too old version of GCC to build on powerpc64, but
rely on the system compiler (even if that means we need to be explicitly
conservative when it comes to optimizations). [1]
Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there.
PR: 235975 [1]
Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1]
Simplify the creation of the multilib-related sub-directory tree on
powerpc64 and avoid leaving an empty directory behind on the way. [1]
Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there.
PR: 235964, 231804 [1]
Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [1]
which caused the build to fail after the update to binutils 2.31 and was
factually incorrect anyways (the oldest we support being 8548). [1]
On the way update to the 20180201 snapshot of GCC 8.2.1.
PR: 235393 [1]
Reported by: jhibbits [1]
Tested by: jhibbits [1]
Forward port r490785 | gerald | 2019-01-20 from lang/gcc8: [1]
Update files/patch-spe-config (and with that our local adjustments to
config.gcc) to the changed directory structure under gcc/config brought
by GCC 8 when powerpcspe was cloned and broken out from the regular
powerpc port.
PR: 234419 [1]
Submitted by: jhibbits [1]
MFH: 2019Q1 (build fix on powerpcspe) [1]
Forward port r469788 from lang/gcc6 = backport r475105 from lang/gcc8:
Filter the -mretpoline command-line option, which is understood by
recent versions of clang (and used in the context of the Spectre
security issues), but not GCC (which uses different options for the
same) from CFLAGS and CXXFLAGS.
This avoids the build of this port via bootstrap, which is the default
and leverages both the system compiler (clang in most cases) plus a just
built version GCC, to fail due to the latter not knowing -mretpoline.
PR: 228205
Submitted by: rozhuk.im@gmail.com
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
