NOAA-PMEL/PyFerret

Pyferret 7.4 not portable

Closed this issue · 3 comments

oliviermarti commented

I've just downloaded Pyferret. I get :

marti@Spip-~/.../softs/PyFerret 👉  bash bin/pyferret
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/marti/local/softs/PyFerret/lib/python2.7/site-packages/pyferret/__init__.py", line 45, in <module>
    from pyferret import libpyferret
ImportError: dlopen(/Users/marti/local/softs/PyFerret/lib/python2.7/site-packages/pyferret/libpyferret.so, 2): Library not loaded: /Users/ksmith/.local/opt/netcdf/lib/libnetcdff.6.dylib
  Referenced from: /Users/marti/local/softs/PyFerret/lib/python2.7/site-packages/pyferret/libpyferret.so
  Reason: image not found
>>>

Olivier

oliviermarti commented

Hello,

This for pyferret on python 2.7. I'ts OK with python 3.6 👍

Olivier

karlmsmith commented

I was successful downloading and running the Python 2.7 version on a system without Homebrew netcdf /netcdff. The Python 2.7 and Python 3.6 version use the same method of finding the dylib libraries (and use the same dylib libraries).

The pyferret script sets/adds to DYLD_FALLBACK_LIBRARY_PATH to give the location of these .dylib libraries. The pyferret script is created from the updated template file by the Finstall and uses the value of FER_DIR you provided in that script. Please make sure your pyferret script includes this DYLD_FALLBACK_LIBRARY_PATH definition and the other values in this (and ferret_paths) scripts have the correct values in them.

I have experienced something similar when the value of FER_DIR given does not point to the new installation; in my case, I have a generic symbolic link that points to the latest version and I refer to the symbolic link instead of the actual directory for FER_DIR. It ends up modifying the script under the symbolic link (old) directory if I have not first updated the symbolic link to point to the new directory.

oliviermarti commented