Re: https://trac.macports.org/ticket/62578
Is there a python or Portfile one-liner fix for the incorrect @rpath issues in
py-scipy’s shared objects?
We can code up an exhaustive search of the build for all the .so's and use
install_name_tool-correct to correct this, but if possible I’d like to use an
existing, simpler approach.
Current issue:
$ python3 -c 'from scipy import special'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/scipy/special/__init__.py",
line 633, in <module>
from . import _ufuncs
ImportError:
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/scipy/special/_ufuncs.cpython-39-darwin.so,
2): Library not loaded: @rpath/libmkl_rt.dylib
Referenced from:
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/scipy/special/_ufuncs.cpython-39-darwin.so
Reason: image not found
$ find
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/scipy
-type f -name '*.so' -exec fgrep -l '@rpath' {} ';' | xargs otool -L | fgrep
'@rpath'
@rpath/libmkl_rt.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libmkl_rt.dylib (compatibility version 0.0.0, current version 0.0.0)
…
@rpath/libmkl_rt.dylib (compatibility version 0.0.0, current version 0.0.0)
smime.p7s
Description: S/MIME cryptographic signature
