Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Feb 2019 10:15:01 -0500
From:      Diane Bruce <db@db.net>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        "Russell L. Carter" <rcarter@pinyon.org>, FreeBSD Ports ML <freebsd-ports@freebsd.org>
Subject:   Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
Message-ID:  <20190217151501.GA68620@night.db.net>
In-Reply-To: <f6a45ec9-7ae4-d9ba-f71c-f2ef8c235039@grosbein.net>
References:  <a2102b4e-7d7a-7d5b-2ba1-b9a14f8574f6@pinyon.org> <f6a45ec9-7ae4-d9ba-f71c-f2ef8c235039@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org db@db.net http://artemis.db.net/~db



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190217151501.GA68620>