You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm seeing a sporadic failure in the conda-lock CI when running with micromamba on osx-arm64. I would estimate the frequency of failure to be around 10%.
+ micromamba run -n gdal-test-mm-lock gdalinfo --version
+ local cmd=run
+ case"${cmd}"in
+ __mamba_exe run -n gdal-test-mm-lock gdalinfo --version
+ /Users/runner/micromamba-bin/micromamba run -n gdal-test-mm-lock gdalinfo --version
dyld[2884]: Library not loaded: @rpath/libarchive.13.dylib
Referenced from: <AF2F33F0-47DF-3AD6-B501-D354725FEBD8> /Users/runner/micromamba/pkgs/libgdal-core-3.9.2-hfd0b032_7/lib/libgdal.35.3.9.2.dylib
Reason: tried: '/Users/runner/micromamba/pkgs/libgdal-core-3.9.2-hfd0b032_7/lib/libarchive.13.dylib' (no such file), '/Users/runner/micromamba/pkgs/libgdal-core-3.9.2-hfd0b032_7/bin/../lib/libarchive.13.dylib' (no such file), '/Users/runner/micromamba/pkgs/libgdal-core-3.9.2-hfd0b032_7/bin/../lib/libarchive.13.dylib' (no such file), '/usr/local/lib/libarchive.13.dylib' (no such file), '/usr/lib/libarchive.13.dylib' (no such file, not in dyld cache)
Error: Process completed with exit code 134.
@maresb: the problem that you describe is rather due to libgdal-core which improperly relatively searches for libarchive's the shared library. I would recommend opening an issue on https://github.com/conda-forge/gdal-feedstock.
I don't understand much about how shared libraries work, but my interpretation is that libgdal-core should not be searching for libarchive, but should instead directly find the one provided by conda-forge.
Issue
I'm seeing a sporadic failure in the conda-lock CI when running with
micromamba
onosx-arm64
. I would estimate the frequency of failure to be around 10%.An example of a failing run is here.
The relevant output is:
I originally reported this error in mamba-org/mamba#1826 (comment). I got a response from @jjerphan in the second half of mamba-org/mamba#1826 (comment). In particular, he wrote,
I don't understand much about how shared libraries work, but my interpretation is that
libgdal-core
should not be searching forlibarchive
, but should instead directly find the one provided by conda-forge.Installed packages
Expand for environment creation logs
The text was updated successfully, but these errors were encountered: