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

[Diane Bruce]

On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote:
> 17.02.2019 8:02, Russell L. Carter wrote:
> 
> > Greetings,
> > 
> > Restarting the FreeCAD 0.17 discussion on a different tangent.
> > 
...
> > /usr/local/lib/gcc8/libgfortran.so.5 not found
> > 
> > This is probably fatal to practical use of FreeCAD on FreeBSD.  I was
> > able to open most of my previous models, created on debian-testing,
> > but some were fail.
> > 
> > 2 threads, no happy ending:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html
> > https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html
> > 
> > Question to experienced porters, how is this best practice solved?

I've just updated my wiki entry. I think the old entry was way too
long so the TLDR; solution I suggest comes first

https://wiki.freebsd.org/libgcc%20problem#preview

The problem is simple. Python code is not linked with libgcc_s
so the system 'fake' libgcc_s is preferred over the one that Fortran
prefers since python doesn't 'know' about gfortran at all no RPATH
is ever seen in time. Hence if a python binary module is loaded that does use 
libgcc_s.so it's the system libgcc_s not the one that Fortran "needs".

> 
> I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got this:
> 
> # ldd /usr/local/lib/gcc8/libgfortran.so.5
> /usr/local/lib/gcc8/libgfortran.so.5:
>         libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000)
>         libz.so.6 => /lib/libz.so.6 (0x8016ad000)
>         libm.so.5 => /lib/libm.so.5 (0x8018c5000)
>         libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000)
>         libc.so.7 => /lib/libc.so.7 (0x800823000)
> 
> So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1
> but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case.
> 
> I assume something is broken in your installation. Try removing gcc8 and reinstalling
> it using package.

No, it's as I outlined above. I have a possible longer term
transparent workaround I've mentioned to @emaste but it will take
some trivial port changes.

Basically all we need is a pre-loader script for interpreters
that run into this such as python. (I suspect there have to be other
interpreters that run into this.) Perhaps something like 
python2_gfortran or the like, all it has to do is PRELOAD or modify
the library path  so we get the 'right' libgcc_s.so.


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