Problems with out libgcc_s.so in base

[Steve Kargl]

On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans <tijl at FreeBSD.org> wrote:
> > 
> > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> ...
> >> % ldconfig -r | grep libgcc
> >>        6:-lgcc_s.1 => /lib/libgcc_s.so.1
> >>        735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> >> 
> >> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> >> be convinced to build, install, and use libgcc_s6.so.1, then the
> >> problem is solved without a wrapper.
> > 
> > In this case the real cause of the problem is that compilers and linkers
> > search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> > the library is just a hack around that.
> 
> Well, even if you would adjust the compilers and linkers to look in
> /usr/local/lib first, how would you solve the problem of having
> multiple, possibly incompatible versions of the same library in
> different directories?
> 
> For example, on one of my systems, I now have these:
> 
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> So which one are you going to put at the front of the path?  The gcc7
> version?  If you are lucky that one is backwards compatible with all the
> previous ones, but still I would like it much better if a program
> compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> of libgcc_s.so.
> 
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.


I asked on the gcc at gcc.gnu.org if there is a configure option
to go the above, and unfortunately there isn't.  I was pointed
to --enable-version-specific-runtime-libs, but was then told
that whatever it does is broken for multilib installs.

I had not considered libtool-like utilities, so Dimitry is probably
right in that this may open a can of worms.

Another hack for the ports system would be to unilaterally include
an -Wl,-rpath option on the gfortran commmand line.  Currently, 
-Wl,-rpath is added to FFLAGS, FCFLAGS, and LDFLAGS in fortran.mk.
The problem is that some ports might reset FFLAGS after fortran.mk
has been included in Makefile.   This should do the trick (watch
for cut-n-paster whitespace corruption):

Index: fortran.mk
===================================================================
--- fortran.mk  (revision 419226)
+++ fortran.mk  (working copy)
@@ -26,9 +26,8 @@
 RUN_DEPENDS+=  gfortran${_GCC_VER}:lang/gcc${_GCC_VER}
 .endif
 USE_BINUTILS=  yes
-F77=           gfortran${_GCC_VER}
-FC=            gfortran${_GCC_VER}
-FFLAGS+=       -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+F77=           gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+FC=            gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
 FCFLAGS+=      -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
 LDFLAGS+=      -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
                -L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

One potential issues may be mixed-language apps that use Fortran libraries,
but link with gcc or g++.

-- 
Steve