1
10 months ago by
jet45610
jet45610 wrote:

Hi,

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

I do:

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


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

** R
** inst
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded


Has anyone else experienced this?

modified 10 months ago • written 10 months ago by jet45610

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.

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

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

Thank you.

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.

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.

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

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.

3
10 months ago by
Martin Morgan ♦♦ 23k
United States
Martin Morgan ♦♦ 23k wrote:

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;


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. ADD COMMENTlink modified 10 months ago • written 10 months ago by Martin Morgan ♦♦ 23k Thanks Martin. ADD REPLYlink written 10 months ago by Wei Shi3.0k Thanks a lot. It solves my problem perfectly ADD REPLYlink written 10 months ago by 5629867550 Thank you, that's a great explanation and it fixed my error! ADD REPLYlink written 10 months ago by jet45610 Answer: Rsubread install fails, "unable to load shared object Rsubread.so" 3 10 months ago by Yang Liao100 Australia Yang Liao100 wrote: 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 COMMENTlink modified 10 months ago • written 10 months ago by Yang Liao100 2 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)
{
}

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.

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.

0
10 months ago by
jet45610
jet45610 wrote: