Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

faToTwoBit: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file #110

Closed
CB017 opened this issue Feb 15, 2019 · 7 comments

Comments

@CB017
Copy link

CB017 commented Feb 15, 2019

Hello,
I am fairly new to this so apologies if this is a simple error on my part!
I downloaded fusioncatcher via conda and have been running it on both test samples from the manuel and some downloaded GEO RNAseq data. In both cases there is an error at step 369 which means I do not reach the final list of transcripts (see below). The preliminary list looks ok.
Very grateful for your help and many thanks!

////////////////////////////////////////////////////////////////////////////////
  Running: step = 369   Time: 01:52   Date: 2019-02-12 (elapsed time: 0d:1h:31m)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
==> Current working directory: '/GEO_downloads'
faToTwoBit \
 /GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.fa \
/GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.2bit \
-noMask 
--------------------------------------------------------------------------------
+-->EXECUTING...


ERROR: Workflow execution failed at step 369 while executing:
----------------
   faToTwoBit \
    /GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.fa \
    /GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.2bit \
   -noMask 
----------------
  * Size '/GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.fa' = 127799382 bytes
  * Size '/GEO_downloads/kasumi_1/kasumi_fusions/gene-gene.2bit' = 0 bytes


Executing second time the same step/command in order to capture error messages (i.e. STDERR)...

-------------------------------------------
faToTwoBit: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory


################################################################################
################################################################################
TOTAL RUNNING TIME: 0 day(s), 1 hour(s), 30 minute(s), and 20 second(s) 
################################################################################
################################################################################
@ndaniel
Copy link
Owner

ndaniel commented Feb 15, 2019

FusionCatcher installation thru conda is new and I perform tests right now.

It might be that the issue is related regarding the the conda channels are in wrong order? How does your .condarc file looks like?

@matq007
Copy link

matq007 commented Feb 15, 2019

Ah, I've seen this problem many times. A dirty and quick workaround is to create a symlink.

ln -s /lib/x86_64-linux-gnu/libssl.so.1 /lib/x86_64-linux-gnu/libssl.so.1.0.0

@CB017
Copy link
Author

CB017 commented Feb 16, 2019

Thanks very much - I'll try this!

@ndaniel ndaniel closed this as completed Feb 18, 2019
@ScubaChris
Copy link

matq007 has the right idea, but it has to be inside the conda env. Assuming your env name is 'fusioncatcher':

ln -s ~/miniconda3/envs/fusioncatcher/lib/libssl.so.1.1 ~/miniconda3/envs/fusioncatcher/lib/libssl.so.1.0.0
ln -s ~/miniconda3/envs/fusioncatcher/lib/libcrypto.so.1.1 ~/miniconda3/envs/fusioncatcher/lib/libcrypto.so.1.0.0

@pbiology
Copy link
Contributor

pbiology commented Jul 8, 2020

This is still not fixed. I installed fusioncatcher now with conda and am still getting the problem. The solution by @ScubaChris worked to solve it, but should be integrated into the conda install solution.

I did find the similar issue and solution here: PacificBiosciences/pbbioconda#85

@matq007
Copy link

matq007 commented Jul 8, 2020

Hey @pbiology I am using bioconda::fusioncatcher=1.20 and it works without any issue.

@pbiology
Copy link
Contributor

pbiology commented Jul 8, 2020

I seem to be getting some strange results.

I get different conda environments depending on how I create them.
Using either a one-line command:
$ conda create -p conda_env/fuscat fusioncatcher=1.20
or if I generate the environment from a environment.yml file
$ conda env create -f environment.yml -p conda_env/fusion-catcher
For this, my environment.yml file looks like this:

name: fusion-catcher
channels:
  - bioconda
dependencies:
  - fusioncatcher==1.20

Generating the environment from the environment.yml file gives me errors while running the fusion-catcher pipeline

This might be outside of the scope for fusioncatcher to fix, but I'd thought I'd mention it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants