Question

Rsubread install fails, "unable to load shared object Rsubread.so"

1

Entering edit mode

jet456 ▴ 10

@jet456-15916

Last seen 6.6 years ago

Hi,

I'm running CentOS 6.9, R 3.5.0, installing Rsubread.

I do:

source("https://bioconductor.org/biocLite.R")
biocLite("Rsubread")

The installation gets most of the way through before this message:

** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error: package or namespace load failed for ‘Rsubread’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/apps/R-3.5.0/lib64/R/library/Rsubread/libs/Rsubread.so':

Has anyone else experienced this?

rsubread • 3.3k views

ADD COMMENT • link 6.6 years ago • updated 6.5 years ago jet456 ▴ 10

0

Entering edit mode

Can you provide the complete screen output from your installation? The 'Rsubread.so' file is generated after the gcc compilation is successfully completed. If the gcc compilation failed then you wouldn't get the Rsubread.so file generated and Rsubread won't be loaded.

ADD REPLY • link 6.6 years ago Wei Shi ★ 3.6k

0

Entering edit mode

Sure, I'll re-run it in the morning and attach the output. Thank you--

ADD REPLY • link 6.6 years ago jet456 ▴ 10

0

Entering edit mode

Bioconductor won't let me paste the entire thing here. The output: https://pastebin.com/qGqH9Y0U

Thank you.

ADD REPLY • link 6.6 years ago jet456 ▴ 10

0

Entering edit mode

The 'Rsubread.so' file was successfully generated and the compilation seems to be OK. I dont know what caused the problem. Maybe try reinstall your R and then install Rsubread so you can install it in a fresh session.

ADD REPLY • link 6.6 years ago Wei Shi ★ 3.6k

0

Entering edit mode

Our R is compiled in a nonstandard way. Reinstalling to a fresh directory didn't help. I tried manually compiling Rsubread (downloading/extracting source code, running configure and gcc commands) and the Rsubread.so file has been generated, but I'm not sure where the "testing if installed package can be loaded" bit is hiding. My guess is that R isn't finding the .so file. Will continue looking.

ADD REPLY • link 6.6 years ago jet456 ▴ 10

0

Entering edit mode

hello, I meet the same problem. could you please show me the detail of compiling Rsubread?

ADD REPLY • link 6.6 years ago 562986755 • 0

0

Entering edit mode

Unfortunately I haven't been able to get it to run. I also tried installing it to our Ubuntu Linux environment which is standard, using R 3.5.0 (the code I posted above is CentOS with an unusual configuration). Same error in both places. It looks like something's wrong with the library file.

ADD REPLY • link 6.6 years ago jet456 ▴ 10

score 3 · Answer 1 · 2018-05-30

I see this problem too, on my Linux machine with

Rsubread master$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

It's solved by removing the 'inline' keyword at

Rsubread master$ git diff
diff --git a/src/LRMsorted-hashtable.c b/src/LRMsorted-hashtable.c
index e0eae63..ba89881 100644
--- a/src/LRMsorted-hashtable.c
+++ b/src/LRMsorted-hashtable.c
@@ -34,7 +34,7 @@
 #define _gehash_hash(k) ((unsigned int)(k))
 #define WITHOUT_CLUSTER_ORDERING 0

-inline struct LRMgehash_bucket * LRM_gehash_get_bucket(LRMgehash_t * the_table, LRMgehash_key_t key)
+struct LRMgehash_bucket * LRM_gehash_get_bucket(LRMgehash_t * the_table, LRMgehash_key_t key)
 {
        int bucket_number;

or by adding 'static'

Rsubread master$ git diff .
diff --git a/src/LRMsorted-hashtable.c b/src/LRMsorted-hashtable.c
index e0eae63..7599faf 100644
--- a/src/LRMsorted-hashtable.c
+++ b/src/LRMsorted-hashtable.c
@@ -34,7 +34,7 @@
 #define _gehash_hash(k) ((unsigned int)(k))
 #define WITHOUT_CLUSTER_ORDERING 0

-inline struct LRMgehash_bucket * LRM_gehash_get_bucket(LRMgehash_t * the_table, LRMgehash_key_t key)
+static inline struct LRMgehash_bucket * LRM_gehash_get_bucket(LRMgehash_t * the_table, LRMgehash_key_t key)
 {
        int bucket_number;

I have a vague recollection that this is because the compiler inlines and then removes the function from the .o file, but retains the annotation that it exists in the .so file. Removing 'inline' means that it's not inlined so still available; adding 'static' means that the function is not advertised as available. This [StackOverflow][1] link provides an entrez into this exciting world.

[1]: https://stackoverflow.com/questions/6312597/is-inline-without-static-or-extern-ever-useful-in-c99

score 3 · Answer 2 · 2018-05-31

3

Entering edit mode

Yang Liao ▴ 450

@yang-liao-6075

Last seen 7 days ago

Australia

I understand that the "inline" keyword instructs the compiler to embed the function into all its callers, and modern compilers are smarter to automatically make the decision, leaving this keyword obsolete. However, it should be harmless when you build a shared object from the codes including inline functions. The compiler just forgets the function names at all after it embeds the inline functions into the callers.

My computer runs CentOS 6.4, and I used R 3.5.0 and GCC 5.4.0 to install the Rsubread package (v1.30.2) from source codes and had no error reported. I then used gdb and strings to find all names in Rsubread.so that I have just built, and there is no "LRM_gehash_get_bucket" in the shared object.

I can remove this keyword from the source codes but I'm wondering if something else caused the problem.

ADD COMMENT • link 6.6 years ago Yang Liao ▴ 450

2

Entering edit mode

You and I might think "The compiler just forgets the function names at all after it embeds the inline functions into the callers" but that's not what happens. For instance, I compile with -O0 (because I sometimes want to do C-level debugging, and no optimizations help; this can be set in a file ~/.R/Makevars with line CFLAGS = -g -O0 ). I did

~/b/git/Rsubread master$ R CMD INSTALL .

so that I could look at the build artifacts. Then

~/b/git/Rsubread master$ nm src/LRMsorted-hashtable.o|grep LRM_gehash
U LRM_gehash_get_bucket
~/b/git/Rsubread master$ nm src/Rsubread.so |grep LRM_gehash
U LRM_gehash_get_bucket

so the symbols are still in the object file and shared object library, but (from man nm) "U"ndefined. If I compile with optimizations, then the function is definitely inlined by the compiler, and removed from the translation units. The original poster is using -std=gnu99 (from their pastebin output) where the behavior is specifically documented and rationalized, e.g., in the body of this post where the example

inline const char *saddr(void)
{
    static const char name[] = "saddr";
    return name;
}
int compare_name(void)
{
    return saddr() == saddr(); // unspecified behavior
}

Is said not to be reliable, "Since the implementation might use the inline definition for one of the calls to saddr and use the external definition for the other, the equality operation is not guaranteed to evaluate to 1 (true)". I don't think you can assume or force non gnu99 or only optimized code compilation, so your code has to be robust to these conditions.

ADD REPLY • link 6.6 years ago Martin Morgan 25k

0

Entering edit mode

Thanks for the detailed explanation! Yes, I can now reproduce the error by adding "-O 0" to the compiler parameters. It is a little surprising to see that an optimisation option can change the legitimate behaviour of the compiler.

I have removed this keyword from my codes.

ADD REPLY • link 6.6 years ago Yang Liao ▴ 450

score 0 · Answer 3 · 2018-06-05

0

Entering edit mode

jet456 ▴ 10

@jet456-15916

Last seen 6.6 years ago

Martin Morgan's answer above worked:

C: Rsubread install fails, "unable to load shared object Rsubread.so"

Thank you again.

ADD COMMENT • link 6.5 years ago jet456 ▴ 10