Runtime loader issue

[Gleb Popov]

On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
sgk at troutmask.apl.washington.edu> wrote:

> 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.
>

Our libgcc also lacks some functionality compared to the original one:
https://reviews.freebsd.org/D11482


> --
> Steve
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>