FreeCAD 0.17 && /lib//libgcc_s.so.1

[Steve Kargl]

On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce <db at db.net> wrote:
> > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce <db at db.net> wrote:  
> >>> Except python doesn't have an rpath which is why this keeps coming
> >>> up over and over again.  
> >> 
> >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
> >> without depending on gcc.  Then python should use gcc libgcc_s when
> >> it exists and fall back to base system libgcc_s when it doesn't.  
> > 
> > Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed
> > a specific port will require a fortran built binary module later.
> > 
> >> Maybe we should compile *all* ports with gcc rpaths without depending
> >> on gcc, just like we already compile everything with -fstack-protector
> >> in LDFLAGS.
> >> 
> >> There's also the fact that gfortran behaves differently from the C
> >> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
> >> always links with libgcc_s.  The C compilers link with libgcc.a first
> >> and then with libgcc_s only as needed.  This eliminates almost all  
> > 
> > What is really happening is gfortran links with libgfortran (surprise 
> > surprise) and libgfortran has the requirement for @GCC_4.6.0 or later
> > 
> >> links with libgcc_s.  The only ones left are for exception handling
> >> and stack unwinding and gcc libgcc_s and base system libgcc_s are
> >> version compatible for that so it doesn't matter which one gets picked
> >> up.  The attached patch for lang/gcc8 makes gfortran behave just like
> >> the C compilers.  
> > 
> > Something like this was tried already. I'll have to dig into
> > my old notes. 
> 
> With my patch libgfortran only needs GCC_4.2.0 and works with base
> libgcc_s.

Why not bump the major version number of the port?

% svn diff libgcc/
Index: libgcc/config/t-slibgcc
===================================================================
--- libgcc/config/t-slibgcc     (revision 269077)
+++ libgcc/config/t-slibgcc     (working copy)
@@ -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@

Assuming the port system runs ldconfig to update the cache,
one has 

% ~/work/x/bin/gfortran -o z hello.f90
% ldd z
z:
        libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x200800000)
        libm.so.5 => /lib/libm.so.5 (0x200645000)
        libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000)
        libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e70000)
        libc.so.7 => /lib/libc.so.7 (0x2010b0000)
        libz.so.6 => /lib/libz.so.6 (0x200678000)
        libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000)
%  nm z | grep 4.6
                 U __multf3@@GCC_4.6.0
% ./z
   2.00000000000000000000000000000000000  

Note, I'm playing with a test install into a ~/work/x directory.
The ldconfig still has issues with first come first served

% ldconfig -r | grep libgcc_s
        6:-lgcc_s.1 => /lib/libgcc_s.so.1
        806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1
        880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2
%  ldconfig -r | grep libgfortran
        808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5
        876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5

6 is picked up due to libc.so.  806 is picked up due to
808, but won't be there is major version number is
bumped.  876 is the loser of the first come first served, here;
but 808 would be the correct libgfortran point to 880 if I 
had installed into /usr/local/lib/gcc8.  

PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16)
type.
-- 
Steve