bioconda-recipes: samtools 1.9 dependency pulls in wrong version of openssl

For me, changing the channel order did not help. But I was able to solve the problem by explicitly downgrading openssl:

conda install -c bioconda samtools openssl=1.0

This is because the samtools 1.9 depends on openssl 1.0.x (I hope the next version will support or just change the shared library name) and openssl 1.1.x was installed，if you must keep the openssl 1.1.x version, a possible solution is :

1. move to the /*Your_Path_of_conda/lib (for me ~/anaconda3/lib/) folder
2. give a soft link of “libcrypto.so.1.1” named “libcrypto.so.1.0.0” to cheat on the samtools

ln -s libcrypto.so.1.1 libcrypto.so.1.0.0

I am having this exact same issue - how did you solve it precisely?

I had put the channels into my .condarc manually, and they ended up being in the wrong order. I removed them from the file and then followed the instructions on the bioconda page. Now they are in my file as follows:

channels:
  - conda-forge
  - bioconda
  - defaults

I am having this exact same issue - how did you solve it precisely?

Here is a Dockerfile that works using @hdetering recipe:

FROM continuumio/miniconda3:4.5.12

RUN conda update -n base -c defaults conda

RUN conda config --add channels defaults
RUN conda config --add channels bioconda
RUN conda config --add channels conda-forge

RUN conda install -c bioconda -y samtools
RUN conda install openssl=1.0

This old bug also popped up on our side. And I’m not sure how to fix this from the maintainer viewpoint. We have the drop package which depends on samtools>=1.7. When installing drop it pulls samtools=1.7 and openssl 1.1.1g that are not compatible.

conda create --override-channels -c conda-forge -c bioconda -c defaults -n drop-bug1 drop

This should not be past to the end-user as @pb-cdunn already said. Should we as a package maintainer then rather fix the version numbers in our recipes or is there another place we as a maintainer can ensure the correct versions are installed?

Hi @sbamin I also got the same error with bcftools recently in the same environment as of samtools.

but as mentioned earlier by simply getting back the older version of openssl solved the issue.

conda install openssl=1.0

This problem seems to keep cropping up.

I upgraded my Trinity conda installation, and samtools broke because of libcrypto.so.1.1.1 getting installed instead of libcrypto.so.1.0.0. I tried everything listed here, but the only solution that worked was to copy over libcrypto.so.1.0.0 from elsewhere and place it in the /your-conda-path/envs/your-env/lib directory as suggested by @Simon6089. In my case, I simply copied over the copy from /usr/lib/ (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) on an Ubuntu machine into /your-conda-path/envs/your-env/lib. (You can check with ldd $(which samtools) and it should no longer indicate libcrypto.so.1.0.0 => not found but show libcrypto.so.1.0.0 => /your-conda-path/envs/your-env/lib/libcrypto.so.1.0.0) instead.

Just download an old version openssl and copy the libcrypto.so.1.0.0 to the lib file. It’s work for me.

So, if you’re arriving here because your Trinity install broke, try this first.

This problem seems to have returned. I am on Centos7. Things had been working. But now, when I create a new env with nothing but samtools, it uses samtools-1.7. My base-env, created by installing miniconda3, already has openssl-1.1.1g, which might be contributing to the problem.

Simply disabling channel_priority: strict or changing the search order of channels no longer helps. I solved this with conda install samtools=1.9, but this is tough to explain to users of our software.

This is hopefully now fixed properly by rebuilding it against openssl. Thanks to @dpryan79!

@PilarLF please check your conda channel order. https://bioconda.github.io/user/install.html#set-up-channels

@Dr-Handsome, are you sure openssl 1.0 is not required by other packages in your environment? Try conda install samtools openssl=1.1 just to see what the solver says.

Just to add some clarification about the recent samtools 1.9 builds, h8571acd_10 onward looks OK to me, and the conda commands suggested by @PertuyF in #13958 work as expected to force the latest samtools build: conda install samtools=1.9 --force-reinstall (or conda install samtools=1.9=*_11 to do a wildcard match on a specific build).

We were still seeing this issue come up for users with older builds installed but the behavior was inconsistent and perplexing, so I went through and checked the builds, including with different openssl versions. (This may be old news to the maintainers but I figured it might help for clarity for anyone else dropping in on this issue who has a lingering old install.)

• h8ee4bcc_1: works with openssl=1.0 but pulls in 1.1 by default
• h91753b0_2: works with openssl=1.0 but pulls in 1.1 by default
• h91753b0_3: works with openssl=1.0 but pulls in 1.1 by default
• h91753b0_4: depends on openssl=1.0, conflict with 1.1
• h91753b0_5: works with openssl=1.0 but pulls in 1.1 by default
• h57cc563_6: depends on openssl=1.0, conflict with 1.1
• h57cc563_7: depends on openssl=1.0, conflict with 1.1
• h91753b0_8: depends on openssl=1.0, conflict with 1.1
• h43f6869_9: broken dependency resolution as described here
• h8571acd_10: depends on openssl=1.1 (works)
• h8571acd_11: depends on openssl=1.1 (works)

Since some of those earlier ones aren’t specific about the openssl version, we’ve seen installs that were working fine and installs that were broken depending on what openssl package happened to be present and even if there was a libcrypto.so of the right version supplied by the OS. The other builds were self-consistent but then you get conflicts with other packages that want openssl=1.1. But whatever the case the --force-reinstall goes straight to h8571acd_11 (or whatever build the future brings) and fixes it.

Thanks to the maintainers here for seeing the fix through and @PertuyF for the install tips.

For me, changing the channel order did not help. But I was able to solve the problem by explicitly downgrading openssl:

conda install -c bioconda samtools openssl=1.0

This fixed the issue for me. I hope there will be a better permanent solution soon rather than downgrading openssl