Known issues

[jaimergp]

The following items are known and either awaiting a bugfix elsewhere or, if no fix available, a workaround is suggested.

libarchive: "library not loaded" or "cannot open shared object file"

Observed errors

On Linux:

ImportError: libarchive.so.13: cannot open shared object file: No such file or directory

On macOS:

ImportError: dlopen(~/miniconda3/lib/python3.11/site-packages/libmambapy/bindings.cpython-311-darwin.so, 2): Library not loaded: @rpath/libarchive.13.dylib Referenced from: ~/miniconda3/lib/libmamba.2.0.0.dylib Reason: image not found

Explanation

This is a known incompatibility between the libarchive packages published on defaults and conda-forge. The root cause is a problem in the CMake build configuration upstream (libarchive/libarchive#1857).

Solution

This is a packaging problem that will be eventually solved, but that won't happen until libarchive 3.8 is published (or later). For now, the recommendation is to make sure that libarchive and libmamba come from the same channel.

References

• Different soname versions when built using autotools and cmake libarchive/libarchive#1857
• Library not loaded: @rpath/libarchive.13.dyli on M1 Mac mamba-org/mamba#1826
• SONAMEs follow different scheme than upstream (e.g. so.13.5.2 vs so.18) conda-forge/libarchive-feedstock#69
• Latest miniconda incompatible with mamba? conda#13041
• Could not load conda plugin conda-libmamba-solver #244

---

Cannot use defaults::package specs

Observed errors

RuntimeError: The package "pkgs/main::zlib" is not available for the specified platform

InvalidMatchSpec: Invalid spec 'pkgs/main::python': This is a bug in libmamba 1.5.1 when using 'defaults::<spec>' or 'pkgs/main::<spec>'. Consider using '-c defaults' instead.

Explanation

This is a known issue reported in libmamba: mamba-org/mamba#2431

Solution

Fixed in libmamba 1.5.3. Please update to the latest version.

---

Cannot Ctrl-C out of conda

Observed errors

Users are unable to use Ctrl+C to exit conda commands when libmamba is in use.

Explanation

The libmamba C++ library has some custom signal handlers that take over the signal controllers in Python's thread. Instantiating the libmambapy.Context object is enough to install those handlers in the process. This prevents Python from handling SIGINT correctly.

Solution

Fixed in libmamba 1.5.3. A small change is needed in conda-libmamba-solver, and will be made available soon.

In the meantime, users can use a different signal to kill the process. For example, Ctrl+Z to pause it and then issue SIGKILL / 9 via top or htop.

[spyoungtech]

For now, the recommendation is to make sure that libarchive and libmamba come from the same channel.

To expand on this, libarchive seems to come with conda by default (when installed via miniconda). So, even if you're working with a clean conda install and using conda-forge as your only configured channel, you'll get this error until you reinstall libarchive.

I suspect miniforge users won't have this issue.

[gosunny2050]

how to solve it

[noahlibby17]

Any update on how to solve this issue?

[spyoungtech]

@gosunny2050 @noahlibby17

As noted above:

For now, the recommendation is to make sure that libarchive and libmamba come from the same channel.

I'll try to elaborate on this to the best of my ability...

If you run conda list, it will show your installed packages, the version/build, and the channel source. So, if you find the entries for libarchive and libmamba in the output of conda list: BOTH of them should show the same channel (for example, conda-forge). If you see they are installed from different channels, you must uninstall/reinstall one or both of the packages so that they are installed from the same channel.

In my case, I was running into this issue even with a fresh conda base environment (via miniconda) because, by default, libarchive is present and installed from the defaults channel. So, when I installed libmamba from conda-forge, this issue occurred due to the mismatching channels.

To fix this, when I create my environment, I make sure to remove the defaults channel then run conda update --all which will cause all packages to be from conda-forge (assuming you have no other channels configured):

# make sure conda-forge is the only channel
conda config --remove channels defaults
conda config --add channels conda-forge

# update all packages to make sure they're from conda-forge, not defaults
conda update --all

After updating with the new channel configuration, when you run conda list again, you should see they are using the same channel:

$ conda list
# packages in environment at /opt/miniconda:
#
# Name                    Version                   Build  Channel
[...]
libarchive                3.7.2                h2aa1ff5_1    conda-forge
[...]
libmamba                  1.5.6                had39da4_0    conda-forge

[gregorywaynepower]

I was able to resolve this issue by running conda install libarchive within my base environment and giving the defaults channel priority in my .condarc file. Where it replaced the condaforge version with the pkgs/main version.