Runtime loader issue

[Steve Kargl]

In review PR 228007, it came to my attention some individuals are
mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
issue".  See
 
https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html

The problem can be summarized by the following 

% gfortran7 -o z h.f90
% ./z
/lib/libgcc_s.so.1: version GCC_4.8.0 required by \
  /usr/local/lib/gcc7/libgfortran.so.4 not found

gfortran7 is installed from ports/lang/gcc7.  This is not 
a "gfortran's FreeBSD issue".  This is a FreeBSD loader issue.

Specifically, there is a shared library name clash.

% ldconfig -r | grep gcc_
     6:-lgcc_s.1 => /lib/libgcc_s.so.1
   716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1

% ldd z
z:
   libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000)
   libm.so.5 => /lib/libm.so.5 (0x200a17000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000)
   libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000)
   libc.so.7 => /lib/libc.so.7 (0x200ca3000)

So, the runtime loader finds 6 instead of 716, tries to link, 
fails, and issues an error message.  There are a number ways to
fix this issue.

1) By far, the best solution would be to stop hijacking the libgcc
   name in libraries installed on FreeBSD that are not related to
   actual GCC software.

% ls -l /lib/libgcc* /usr/lib/libgcc*
(trimming lines)
/lib/libgcc_s.so.1
/usr/lib/libgcc.a@ -> libcompiler_rt.a
/usr/lib/libgcc_eh.a
/usr/lib/libgcc_eh_p.a
/usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a
/usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1

   Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)?  Yes, I'm
   aware that clang does not work on all archs and the ancient gcc
   lives on.

2) Given the expected push back againt solution 1), this solution
   proposes bumping the library version for /lib/libgcc_s.so.1 from
   1 to some larger value, say, 10.  It is unlikely that GCC will
   bump its shared library number anytime soon.  GCC bumped it from
   0 to 1 some 16 years ago.

   https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316

   This solution, however, papers over the general problem with
   name clashes.

3) This solution is to actually fix the runtime loader.  If an error
   occurs with loading a shared library, then iterate over the entries
   in the hints file to check to see if another hint would satisfy
   the linking.  Here, instead of issuing the above error, the loader
   would find entry 716, and load the correct libgcc_s.so.1.

   Admittedly, I haven't looked to see how difficult this solution
   would be.
   
4) Bump the shared library number of the individual ports.  As a proof
   of concept, I've done this with ports/lang/gcc6.

% cat /usr/ports/lang/gcc6/files/patch-t-slibgcc 
--- libgcc/config/t-slibgcc.orig        2018-05-08 12:47:42.334495000 -0700
+++ libgcc/config/t-slibgcc     2018-05-08 12:45:26.872312000 -0700
@@ -20,7 +20,7 @@
 
 SHLIB_EXT = .so
 SHLIB_SOLINK = @shlib_base_name at .so
-SHLIB_SOVERSION = 1
+SHLIB_SOVERSION = 2
 SHLIB_SONAME = @shlib_base_name at .so.$(SHLIB_SOVERSION)
 SHLIB_MAP = @shlib_map_file@
 SHLIB_OBJS = @shlib_objs@

% ldconfig -r | grep gcc_
     6:-lgcc_s.1 => /lib/libgcc_s.so.1
   716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
   766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2

% gfortran6 -o z h.f90
% ./z
 hello
% ldd z
z:
   libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000)
   libm.so.5 => /lib/libm.so.5 (0x20096c000)
   libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000)
   libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000)
   libc.so.7 => /lib/libc.so.7 (0x200df7000)

   This works for this particular name conflict.  Hopefully, FreeBSD
   never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2.  This,
   however, introduces an incompatibility with what is actually distributed
   by GCC.

Finally, can people stop referring to the above error as
"gfortran's FreeBSD issue".  This is a FreeBSD runtime loader issue.

-- 
Steve