ImagoXV / NanoASV

NanoASV official repo
GNU General Public License v3.0
3 stars 0 forks source link

Docker image run with singularity. Error phyloseq R package : "Cannot open shared object" #61

Closed ImagoXV closed 2 months ago

ImagoXV commented 3 months ago
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/imago/R/x86_64-pc-linux-gnu-library/4.3/stringi/libs/stringi.so':
  libicui18n.so.70: cannot open shared object file: No such file or directory
Execution halted

Something might have changed.

I'm pretty sure that's because of ubuntu:latest

Gotta change for ubuntu 22.04

I'm sure at some point it was specified. IDK what happened

ImagoXV commented 3 months ago

It's no version problem It works fine when running with docker But not with singularity What could be involved

ImagoXV commented 3 months ago

When inside the docker container :

> library(phyloseq)
> 

When inside singularity

> library(phyloseq)
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/imago/R/x86_64-pc-linux-gnu-library/4.3/stringi/libs/stringi.so':
  libicui18n.so.70: cannot open shared object file: No such file or directory
> 
ImagoXV commented 3 months ago

Singularity is modifying environment variables

$ singularity --verbose shell nanoasv 
VERBOSE: Setting HOME=/home/imago
VERBOSE: Setting PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

which of course reults in looking for files outside of the container

Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/imago/R/x86_64-pc-linux-gnu-library/4.3/stringi/libs/stringi.so':
  libicui18n.so.70: cannot open shared object file: No such file or directory

Why you do this. The whole purpose of your existence IS NOT TO USE FILES FROM OUTSIDE OMG

ImagoXV commented 3 months ago
$ singularity shell --containall nanoasv 

The problem with --containall is that singularity stops to mount the filesystem as well. So no access to data. So R works fine, phyloseq package gets loaded without troubles.

The following allows to use R and phyloseq but has no access to the data.

singularity run --containall nanoasv

seems to solve to solve the problem. EDIT: No it does not. It runs fine with shell, but not as nanoasv. I still can't find how to make it run properly

But I don't want to add arguments to my singularity run function.

I want to be able to run my singularity image as an exxecutable. The options being only for nanoasv and not to avoid singularity to do stupid shit

ImagoXV commented 2 months ago
singularity run --no-home nanoasv [...]

Somehow works. But you need to have the fles exactly in the same directory as the nanoasv.sif file I don't want that.

ImagoXV commented 2 months ago

The problem was definitly identified by other users online

https://stackoverflow.com/questions/71252123/singularity-container-with-stringr-fails-only-locally-with-libicui18n-so-66-ca

Which led to its resolution I guess here :

https://github.com/apptainer/singularity/pull/6224

Now I'll figure out to maki it work smoothly

ImagoXV commented 2 months ago

Ok, I'm getting closer, I identified the point where docker and singularity diverge in the case of my problem

When running R inside the docker container :

> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"      
[3] "/usr/lib/R/library"

When running with singularity --containall

> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"      
[3] "/usr/lib/R/library" 

When running singularity run classic way

> .libPaths()
[1] "/home/imago/R/x86_64-pc-linux-gnu-library/4.3"
[2] "/usr/local/lib/R/site-library"                
[3] "/usr/lib/R/site-library"                      
[4] "/usr/lib/R/library"

So maybe, a dumb workaround would be to change these values inside of R so I'm sure it will look for the apropriate package at the expected location. If I can't find how not why those values are injected. N=Can't find how to avoid injection while keeping open access to local file system

So I added the following line to the Rscript

.libPaths(c("/usr/local/lib/R/site-library","/usr/lib/R/site-library","/usr/lib/R/library"))

Which allows

> .libPaths(c("/usr/local/lib/R/site-library","/usr/lib/R/site-library","/usr/lib/R/library"))
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"       "/usr/lib/R/library" 
ImagoXV commented 2 months ago

YES

Worked(around) !