turns out that I had the channels in the wrong order. That will probably fix it

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

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

Thanks a bunch, that worked!

This also worked for me after the same problems with https://bioconda.github.io/recipes/angsd. Many thanks!

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

This has just recently crept back up for me even with channels in the correct order. Can someone post a working Debian Stretch Dockerfile with Bioconda Samtools?

@leipzig not debian but a container: https://quay.io/repository/biocontainers/samtools?tag=latest&tab=tags

Does this help?

So for me it did creep up when setting channels via the commandline using conda install -c where it would pull in the wrong openssl version even when specifying channels in the correct order. However, changing the .condarc channel order did work.

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

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

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

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

I had a very similar issue with DESeq2 which had a depends upon GenomeInfoDb which depended up RCurl which linked to libssl.so.1.0.0:

Error: package or namespace load failed for ‘GenomeInfoDb’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/opt/conda/lib/R/library/RCurl/libs/RCurl.so':
  libssl.so.1.0.0: cannot open shared object file: No such file or directory

Downgrading to openssl 1.0 fixed the issue for me as well.

conda install -c bioconda r-rcurl openssl=1.0

Thanks, @hdetering !

Hello,

same problem solved with @leipzig solution

Thanks!

EDIT: I was pulling an old Docker image by mistake instead of my updated image. Installing openssl v1.0 did indeed fix this problem.

I'm having this problem. I've tried explicitly downgrading openssl to version 1.0, but the same error appears.

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

I've also tried installing them in the same command:

RUN conda install samtools openssl=1.0

As well as downgrading samtools itself:

RUN conda install samtools=1.8 openssl=1.0

Nevertheless I get the same error every time:

samtools: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

Any more ideas?

Sorry, did you run this in Docker? What base image did you choose?

@patrickturko this is my recipe in singularity and it works:

BootStrap: docker
From: continuumio/miniconda3

%setup

mkdir -p ${SINGULARITY_ROOTFS}/users

%post

export PATH=/opt/conda/bin:$PATH


# make sure to have the latest conda version
conda update -n base -c defaults conda

# add some extra channels
conda config --add channels defaults
conda config --add channels bioconda
conda config --add channels conda-forge
conda config --add channels pkgs/r


# install some bioinfo tools from Bioconda
conda install -c bioconda -y samtools
conda install openssl=1.0 # to make work bcftools and samtools 

export PATH=/opt/conda/bin:$PATH

%environment
export PATH=/opt/conda/bin:$PATH

@leipzig yes, this is in Docker, but actually I was mistaken about the bug. See my edit.

In case you missed it, can you try the same commands you were using initially (without the workarounds?). If #13909 is correct the problem should no longer occur.

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?

This is not something that can be fixed without switching to mamba. The conda solver provides incorrect solutions in a number of cases, for which this is an example.

Thank you so much Devon.

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.

Hi guys,

If you are still suffering from the env related issue of falcon, maybe you would like to try this frozen environment of mine, which works well through 2-asm stage.

Simply unzip "pb-assembly.yml.zip", then
conda env create -f pb-assembly.yml

The order of the channel is very important. Please do not change the order unless you have a clear reason.
My conda version is 4.9.2
pb-assembly.yml.zip

If you are using a conda env, simply use

conda install -c bioconda samtools openssl=1.0

If you are using a conda env, simply use

conda install -c bioconda samtools openssl=1.0

Attempting this produced this error for me:

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package zlib conflicts for:
samtools -> curl[version='>=7.59.0,<8.0a0'] -> zlib[version='1.2.|1.2.11']
samtools -> zlib[version='1.2.11.|>=1.2.11,<1.3.0a0|1.2.8.*|1.2.8']

Package openssl conflicts for:
openssl=1.0
python=3.7.10 -> openssl[version='>=1.1.1j,<1.1.2a|>=1.1.1k,<1.1.2a']

Package bzip2 conflicts for:
samtools -> bzip2[version='1.0.*|>=1.0.6,<2.0a0|>=1.0.8,<2.0a0']
python=3.7.10 -> pypy3.7=7.3.5 -> bzip2[version='>=1.0.8,<2.0a0']The following specifications were found to be incompatible with your system:

• feature:/linux-64::__glibc==2.28=0
• feature:|@/linux-64::__glibc==2.28=0
• openssl=1.0 -> libgcc-ng[version='>=7.3.0'] -> __glibc[version='>=2.17']
• python=3.7.10 -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']

This is the first time I've ever seen a message like this... Any explanation or workaround would be greatly appreciated.

Thanks in advance!

This solved it for me.

In short, I (running Bismark in an AWS' Sagemaker Linux environment) ran
conda install "samtools>=1.10"
(exactly as typed above)

and it fixed the dependencies.

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

HOWWWW????? pls

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

i've already change it:
--add channels 'defaults' # lowest priority
--add channels 'bioconda'
--add channels 'conda-forge' # highest priority

In general all releases starting with samtools 1.10 should have the appropriate pinnings and therefore pull in the correct openssl version. We have no other way to fix this until Anaconda finally hopefully someday enables repodata patching for our project.

You can try: conda create -n my_cool_env -c conda-forge -c bioconda samtools=1.9 openssl=1.0 if you really need this version.

thank you for your quick reply!! I''ve tried all suggestions but it keeps failling :c now this is personal

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

After trying all suggestions, only this seems to work for me!! thank you very much