Runtime loader issue

[Steve Kargl]

On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> 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
> 

Interesting page.  I was aware that in the past you tried working
out a solution to the problem.  I did not realize you docoumented
the issue.  A few corrections to your wiki page.

1) The correct spelling of the name of the language is Fortran (with a
   capital F).  It has been the official standard spelling since Fortran
   90.

2) You have "... to always support quad math (*8) and ...".  Quad
   precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard).

3) "subsitute" is normally spelled with an extra 't'. :-)


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

Page doesn't appear to exist?  If I go to 

https://people.freebsd.org/homepage.html

you're not listed.

> > >    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 ;)

Just started reading the source code.  Don't scare the unwary. :-)

-- 
Steve