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

[Diane Bruce]

On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote:
> 17.02.2019 13:19, Steve Kargl wrote:
> 
> > For whatever reason, there are situations where the rpath
> > isn't set in the library.  Read the rtld manpage.  You're
> > hitting #5 in the list.
> 
> Our package building system sets rpath for dependants of gcc8,
> so Fortran libraries (and others) do have rpath for its runtime.
> 
> Setting rpath for resulting binary should solve the problem.

No no no no no. Not for an interpreter. The interpreter doesn't 'know'
you are about to load a binary module that needs libgcc_s and until
it loads something that uses gfortran it doesn't matter
which libgcc_s so it picks the 'wrong' one.

As my wiki page article says: 
We can rename our libgcc (Yes other complications but...)

We can fix our system libgcc to have the missing functions/data that
current libgcc has then bump our version

We can use a specific port which PRELOADs the gfortran libgcc_s.so
e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
it would work)

Individual python ports could be modified to do the PRELOAD with
a tiny sh script e.g. opencad could envoke a small sh script
that then starts the python interpreter. This would mean exposing the
PATH from Mk/USES/fortan.mk

e.g. we currently do this:

FFLAGS+=        -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=       -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=       -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \

We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
exposed

blah. I finally just looked at openscad it's a binary not a python script
As Steve sez it's missing the -Wl,-rpath stuff then

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