mirror of
https://git.freebsd.org/ports.git
synced 2025-04-28 17:46:38 -04:00
4700c3f178
GCC, the GNU Compiler Collection, supports a number of languages. This port installs the C, C++, and Fortran front ends as gcc14, g++14, and gfortran14, respectively. This is the first release from the GCC 14 series. It largely is a copy of lang/gcc14-devel, with release-specific modifications from lang/gcc13. Common issues that could happen when porting code to GCC 14: https://gcc.gnu.org/gcc-14/porting_to.html Changes: https://gcc.gnu.org/gcc-14/changes.html
69 lines
2.8 KiB
Text
69 lines
2.8 KiB
Text
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.
|
|
|
|
Upstream is unlikely accept a patch like this because libgfortran calls
|
|
some _Unwind_* functions and so always needs libgcc_s. Also because
|
|
every Fortran program and library links to libgfortran it makes sense
|
|
that option 2 above is the default. On FreeBSD where clang and GCC
|
|
compiled code can be mixed and where multiple libgcc_s may be installed,
|
|
option 3 is just a lot easier to deal with.
|
|
|
|
The bug that sparked this is PR 208120 (but note there's a lot of
|
|
misleading information in that bug. CMake is not actually doing
|
|
anything wrong.)
|
|
|
|
--- UTC
|
|
--- gcc/fortran/gfortranspec.cc.orig 2022-01-23 22:32:06.000000000 +0000
|
|
+++ gcc/fortran/gfortranspec.cc 2022-02-06 08:56:31.018286000 +0000
|
|
@@ -406,7 +406,7 @@
|
|
}
|
|
}
|
|
|
|
-#ifdef ENABLE_SHARED_LIBGCC
|
|
+#if 0
|
|
if (library)
|
|
{
|
|
unsigned int i;
|
|
--- libgfortran/Makefile.in.orig
|
|
+++ libgfortran/Makefile.in
|
|
@@ -759,7 +759,7 @@
|
|
$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
|
|
$(HWCAP_LDFLAGS) \
|
|
$(LIBM) $(extra_darwin_ldflags_libgfortran) \
|
|
- $(version_arg) -Wc,-shared-libgcc
|
|
+ $(version_arg)
|
|
|
|
libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
|
|
cafexeclib_LTLIBRARIES = libcaf_single.la
|