libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

[Gerald Pfeifer]

Hmm, I received zero feedback on this proposal, when it appeared
important for a number of users.

What's your take, Andreas, Tijl (your patch essentially with a bit
of an updated description), and toolchain?

Gerald

On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
> Hi Tijl, hi everyone, 
> 
> and let me add Andreas who has been helping on the GCC side (both 
> ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
:
> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>> GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
>> doesn't explain why this was done, but we'll have to make the same
>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
>> part of the ABI).  This isn't a blocker for the patch.
>> 
>> I emailed the patch to gerald on 2017-02-21.  He responded in the usual
>> way that he prefers patches submitted upstream and because I thought the
>> patch would not be accepted upstream he proposed an alternative solution
>> where gcc would always add -rpath on FreeBSD so you didn't have to
>> specify it on the command line.  I responded this wouldn't fix the case
>> where clang was used as a linker (e.g. to combine fortran and c++ code
>> in one program) and that the FAQ on the gcc website said it was a bad
>> idea for other reasons.  I also said upstream might accept my patch if
>> it was a configure option but that the gcc configure scripts are
>> complicated and I didn't know where to add it exactly.  Then silence.
> 
> To move this forward, let me include an updated version of the patch
> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for 
> consideration for our ports collection, initially for lang/gcc8 given 
> that this is the default in the ports collection.
> 
> 
> (The lang/gcc* ports actually do carry local patches, e.g. for arm or 
> powerpc or -fuse-ld=lld, but you are right that I usually try to get 
> things upstream first, fixing things upstream myself when I can, or 
> asking for help. The problem in this specific case was/is that I'm 
> quite not enough into this area so cannot really assess and clearly
> stalling over that was not good.)
> 
> 
> Find patch-gfortran-libgcc attached which should simply plug into 
> lang/gcc8/files and lang/gcc8-devel/files.
> 
> Feedback very welcome!
> 
> Gerald
-------------- next part --------------
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 make 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.c.orig	2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
 	}
     }
 
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
   if (library)
     {
       unsigned int i;

--- libgfortran/Makefile.in.orig	2019-02-22 14:22:13.000000000 +0000
+++ libgfortran/Makefile.in	2019-02-27 16:27:08.856408000 +0000
@@ -625,7 +625,7 @@
 	$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
 	$(HWCAP_LDFLAGS) \
 	-lm $(extra_ldflags_libgfortran) \
-	$(version_arg) -Wc,-shared-libgcc
+	$(version_arg)
 
 libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
 cafexeclib_LTLIBRARIES = libcaf_single.la