Problems with out libgcc_s.so in base

[Konstantin Belousov]

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric <dim at FreeBSD.org> 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:
> >>> % gfortran6 -o z foo.f90 && ./z
> >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> >>> /usr/local/lib/gcc6/libgfortran.so.3 not found
> >>> % 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,
> 
> No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last.
> That would match base ld(1) so anything that links successfully at
> compile-time will also link successfully at run-time (if there are no
> other search order mismatches leading to conflicts).
> 
> But, this means that in case of a name conflict between base and ports,
> the ports provided library is assumed to be the right one.  I'm not 100%
> sure this is smart.  Usually the ports version of a library is more
> recent and if the name is the same it should be backward compatible, but
> if that's not the case (older or not compatible) base utilities may fail
> to run (like ./z in the example above) and that's maybe worse than ports
> or locally built programs failing.
> 
> > 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.
> 
> This is a separate problem that has been discussed many times before.
> The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
> a library.  I now noticed there is a FAQ about this at
> https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
> creating wrapper scripts, but they wouldn't work when code is compiled
> with gfortran but linked with Clang cc/c++.  The only thing that works
> in this case is -Wl,-rpath.  Another option would be to create a port
> that installs a recent version of libgcc in /usr/local/lib and let the
> gcc ports use that instead of their own copy.

The option which would fix all this mess is:
1. add rpath for gcc lib/ directory into spec file
and
2. make ports collection use its own compiler instead of fighting with
   the base.