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

[Eugene Grosbein]

17.02.2019 22:41, Diane Bruce wrote:

>> 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

If all involved binaries and libraries in a chain starting from the interpreter
and including libraries have mappings for libgcc_s.so to right file,
the problem should be solved. And libmap.conf(5) should do the job.