Runtime loader issue

[Diane Bruce]

On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> 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

Indeed. I've tried to make it clear it is a name conflict with libgcc
in my own bug reports on the subject.

> >
> > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
> >
> > The problem can be summarized by the following
...
> > 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

Yep.
See https://wiki.freebsd.org/libgcc%20problem

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

Agreed, however this has the side effect of meaning conflicts with libraries
between clang and gcc libs. Notably gfortran and flang use different
conventions for I/O :(

See http://people.FreeeBSD.org/~db/fortran_libs.txt

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

I've argued for this as well and frankly I still think it is the best
solution all around. 

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

Yep. I know work is slowly being done to modernise our libgcc already
but the toolchain folks are busy...

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

This breaks if the bad libgcc is already linked. We'd have to rip
out the original bindings at run time, then re-bind to a new libgcc. 
I looked at the rtld code months ago. Nasty and silly.


> >
> >    Admittedly, I haven't looked to see how difficult this solution
> >    would be.


Very ;)

> >
> > 4) Bump the shared library number of the individual ports.  As a proof
> >    of concept, I've done this with ports/lang/gcc6.
> >
...
> >
> > Finally, can people stop referring to the above error as
> > "gfortran's FreeBSD issue".  This is a FreeBSD runtime loader issue.

Yes, please. I tracked it down to libgcc months ago, made my findings
generally available and yet people are still calling it a libgfortran problem.

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

Yes.


Diane
-- 
- db at FreeBSD.org db at db.net http://www.db.net/~db