SaifAati
Libraries issue
Hi, and thank you for any guidance you can provide on the following-
I'm running to a libraries issue despite following the suggested fix for setting LD_LIBRARY_PATH. I installed the package using the miniconda option.
In running the test script, I receive the following Failed tests: FAILED tests/test_geoCorrelation.py::test_corr[test_corr_config0] - geoCosiCorr3D.geoCore.core_correlation.InvalidCorrLib FAILED tests/test_geoCorrelation.py::test_corr[test_corr_config1] - geoCosiCorr3D.geoCore.core_correlation.InvalidCorrLib FAILED tests/test_geoOpt.py::test_geoOpt - SystemExit: Unable to load the system C library FAILED tests/test_geoOrtho.py::test_ortho_rsm[sinc-30] - SystemExit: Unable to load the system C library FAILED tests/test_geoOrtho.py::test_ortho_rsm[sinc-15] - SystemExit: Unable to load the system C library FAILED tests/test_geoOrtho.py::test_ortho_rsm[bilinear-30] - SystemExit: Unable to load the system C library FAILED tests/test_geoOrtho.py::test_ortho_rsm[bilinear-15] - SystemExit: Unable to load the system C library FAILED tests/test_geoOrtho.py::test_ortho_rfm[sinc-30] - ValueError: Unable to load the system C library/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/lib/lfgeoCosiCorr3D.so FAILED tests/test_tp_gcp_gen.py::test_asift_tps - ValueError: fname must be a string, filehandle, list of strings,
Additionally, when running the cosicorr.py script with the correlate module, I receive: Traceback (most recent call last): File "/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/geoCosiCorr3D/geoCore/core_correlation.py", line 111, in run_correlator lib_cfreq_corr = cdll.LoadLibrary(FREQ_CORR_LIB) File "/Users/wbarnhart/miniconda3/envs/geoCosiCorr3D/lib/python3.9/ctypes/init.py", line 460, in LoadLibrary return self._dlltype(name) File "/Users/wbarnhart/miniconda3/envs/geoCosiCorr3D/lib/python3.9/ctypes/init.py", line 382, in init self._handle = _dlopen(self._name, mode) OSError: dlopen(/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/lib/lgeoFreqCorr_v1.so, 0x0006): tried: '/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/lib/lgeoFreqCorr_v1.so' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/lib/lgeoFreqCorr_v1.so' (no such file), '/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/lib/lgeoFreqCorr_v1.so' (not a mach-o file)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/wbarnhart/Work/PixelTracking/Geospatial-COSICorr3D-main/scripts/cosicorr.py", line 427, in
Hi Will, I ran into the same issue with a miniforge install and then tested with docker, with the image also failing. Their seems to be a dependency error in the default .yml, and pip freezing in docker showed that their were some package differences between the two. I tried to create a better .yml for conda, which worked okay. I've attached it here and also think you might need to do a
pip install -e
in base directory where setup.py and pyproject.toml is located.
I was able to run the test and had
TOTAL 9786 5585 43% ================================================================================================================= short test summary info ================================================================================================================== FAILED tests/test_tp_gcp_gen.py::test_asift_tps - ValueError: fname must be a string, filehandle, list of strings, ============================================================================================ 1 failed, 47 passed, 10 skipped, 73 warnings in 125.47s (0:02:05) =============================================================================================
Which seems to be due to a numpy string problem. It might be a shoestring fix, but I hope it might help! Thanks!
Thomas
I had the same issue on a Mac. I tried various different versions of python, gdal etc. but it looks like the libraries are built for x86-64 so the modern macs with Apple Silicon chips just can't run them properly? The installation went smoothly for me on a linux machine.
>> file lfgeoCosiCorr3D.so
lfgeoCosiCorr3D.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d18785424f26384732a298b25b7a670e206975d0, not stripped
I had the same issue on a Mac. I tried various different versions of python, gdal etc. but it looks like the libraries are built for x86-64 so the modern macs with Apple Silicon chips just can't run them properly? The installation went smoothly for me on a linux machine.
>> file lfgeoCosiCorr3D.so lfgeoCosiCorr3D.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d18785424f26384732a298b25b7a670e206975d0, not stripped
Hi Eleanor, have you tried launching a Rosetta 2 enabled terminal on your Mac? That might allow the old x86 Mac libraries to function.
I did some deep investigation on this and the error output ELF 64-bit LSB shared object meant that these codes are compiled using Linux. They will not work in any macOS machines. For them to work in macOS, the codes need to be recompiled and these recompiled codes should be in Mach-O 64-bit x86_64 or Mach-O arm64.
I already requested the developer to provide us the source codes so we can compile it on our own native machines (https://github.com/SaifAati/Geospatial-COSICorr3D/issues/33).
