On 2/17/19 9:16 AM, Eugene Grosbein wrote:
17.02.2019 22:46, Diane Bruce wrote:

We already have libmap.conf(5). It should be possible to work around the problem
creating /usr/local/etc/libmap.d/python.conf with contents:

[python2.7]
libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1

[python3.4]
libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1


Sure but I'm guessing not all python ports *need* gfortran hence
we shouldn't force all python coded ports to use the gfortran libgcc_s.so

libmap.conf(5) manual page documents how to restrict such mappings 
per-directory.
One can create symlink for the interpreter and restrict the mapping for symlink 
only.

Moreover, the libmap would have to be updated everytime gfortran got
updated

Not quite: libgcc_s.so.1 needs mapping for interpreter only as our port 
building system
already creates libgfortran.so with right rpath for libgcc_s.so.1:

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



Ok, back from RL.  I see a lot of discussion, and am totally agnostic
about what the "correct" solution is.  I read Diane Bruce's page and
ran the script:

# DB solution
# https://wiki.freebsd.org/libgcc%20problem
export LD_PRELOAD=/usr/local/lib/gcc8/libgcc_s.so
FreeCAD $*

No libgcc_s.so.1 problems over three consecutive test all runs.
'FreeCAD' is a binary executable that runs a lot of python under the
hood.  That's what I needed, thank you to all.

Regards,
Russell


_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to