Skip to content

[Bioc-devel] libRblas and libRlapack are broken dependencies for packages in R 3.1.0 on Fedora 20

6 messages · E N, Martin Morgan

Original
E N
# 
[@localhost ~]$ locate liblapack
/usr/lib64/atlas/liblapack.so.3
/usr/lib64/atlas/liblapack.so.3.0

[@localhost ~]$ locate libblas
/usr/lib64/libblas.so.3
/usr/lib64/libblas.so.3.4
/usr/lib64/libblas.so.3.4.2

[@localhost ~]$ R CMD locate liblapack
/usr/lib64/atlas/liblapack.so.3
/usr/lib64/atlas/liblapack.so.3.0

[@localhost ~]$ R CMD locate libblas
/usr/lib64/libblas.so.3
/usr/lib64/libblas.so.3.4
/usr/lib64/libblas.so.3.4.2

R finds its BLAS and LAPACK dependencies, but packages can't. I'm neither a system packager nor an R package writer, but from the Tom?Callaway's message I understood the following:
+prior R-3.1.0 on Fedora, packages could link to?BLAS & LAPACK bundled with R regardless the system (un)provided similar libraries;
+since that R release, packages can no more search dependencies within R shared lib, they ought use the system ones.

Let's reuse 'preprocessCore' as an example. When <grep -nri 'lapack'> is applied to?its sources, there are outputs for?"matrix_functions.c" and?"matrix_functions.c". Both files carry the following includes:
#include <R_ext/Rdynload.h>
#include <R.h>
#include <Rdefines.h>
#include <Rmath.h>
#include <Rinternals.h>

I suspect the problems stem from there. If I didn't miss Tom?Callaway's point?so far, such includes should be replaced by system's (i.e. Fedora).

Eric.

P.S. I left the whole conversation history in this mail to make it visible on the mailing list, which I should have done in my previous messages, sorry for my inadvertence.
Martin Morgan
#
On 05/06/2014 12:29 PM, E N wrote:
Those are the headers, and are relevant to the part of the compilation that you 
elided out [...]. The problem you see

 >>> gcc -m64 -std=gnu99 -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches -m64 -mtune=generic -flto -fpic -Wl,-z,relro -o 
preprocessCore.so R_colSummarize.o R_plmd_interfaces.o R_plmr_interfaces.o 
R_rlm_interfaces.o R_subColSummarize.o R_subrcModel_interfaces.o avg.o avg_log.o 
biweight.o init_package.o lm.o log_avg.o log_median.o matrix_functions.o 
median.o median_log.o medianpolish.o plmd.o plmr.o psi_fns.o qnorm.o rlm.o 
rlm_anova.o rlm_se.o rma_background4.o rma_common.o weightedkerneldensity.o 
-lpthread -llapack -lblas -lgfortran -lm -lquadmath -L/usr/lib64/R/lib -lR
 >>>
 >>> /usr/bin/ld: cannot find -llapack
 >>> /usr/bin/ld: cannot find -lblas

is with linking; R is not able to find your blas and lapack libraries. I guess 
the following simple commands fail for you -- create a simple C source code file

$ cat > tmp.c
int main(int argc, const char **argv) {}

(press cntrl-D after typing the above, so you have a file 'tmp.c' with that 
single line of code) and try to

$ gcc -m64 -lblas tmp.c
$ ./a.out
$

For me gcc finds libblas, and creates an executable file a.out, which actually 
does nothing. For you I guess you'll see something like the following, where 
I've replaced '-lblas' with a reference to some imaginary library that my system 
knows nothing about

$ gcc -m64 -limaginary tmp.c
/usr/bin/ld: cannot find -limaginary
collect2: error: ld returned 1 exit status
$

If this is the case, then somehow your package manager has installed the lapack 
and blas packages without making their location known to other programs. 
Libraries are usually discovered via ldconfig, and I have for instance

$ ldconfig -p|grep blas
	libgslcblas.so.0 (libc6,x86-64) => /usr/lib/libgslcblas.so.0
	libgslcblas.so (libc6,x86-64) => /usr/lib/libgslcblas.so
	libf77blas.so.3 (libc6,x86-64) => /usr/lib/libf77blas.so.3
	libcblas.so.3 (libc6,x86-64) => /usr/lib/libcblas.so.3
	libblas.so.3 (libc6,x86-64) => /usr/lib/libblas.so.3
	libblas.so (libc6,x86-64) => /usr/lib/libblas.so


You might have success with

$ sudo ldconfig

but after this I'll let someone with access to a fedora system step in.

Martin

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      E N
    

    

      
      #
    

  


  

          

      
      
      
    

        
Indeed, you are right M. Morgan ! After a <sudo yum install lapack-devel blas-devel>, GCC passes the <gcc -m64 -lblas tmp.c> example which wasn't the case before lapack-devel and blas-devel were installed. Thereafter, even the biocLite("preprocessCore") is now running quite well.

That's weird because at <http://koji.fedoraproject.org/koji/rpminfo?rpmID=4985034>?blas-devel and?lapack-devel are listed in?dependency?list, but this is no more a Bioconductor or R problem, it's Fedora R package's.?Thanks a lot!

Best wishes,
Eric.

  
  


  


      

    

    

      
      

        


  

        

      E N
    

    

      
      #
    

  


  

      
Mr Morgan,

I'm afraid the issue is not completely over. Among the packages that were failing installation, all now success after your guidance but three remain failing. Here are excerpts of the dumps:

ChIPseqR
gcc -m64 -std=gnu99 -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -fpic -Wl,-z,relro -o ChIPseqR.so startScore.o -L/usr/lib64/R/lib -lR
installing to /usr/lib64/R/library/ChIPseqR/libs
** R
** inst
** preparing package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) :?
unable to load shared object '/usr/lib64/R/library/fBasics/libs/fBasics.so':
libRblas.so: cannot open shared object file: No such file or directory


IdMappingAnalysis
** preparing package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) :?
? unable to load shared object '/usr/lib64/R/library/mclust/libs/mclust.so':
? libRlapack.so: cannot open shared object file: No such file or directory

RamiGO:
** preparing package for lazy loading
Error : .onLoad failed in loadNamespace() for 'igraph', details:
? call: dyn.load(file, DLLpath = DLLpath, ...)
? error: unable to load shared object '/usr/lib64/R/library/igraph/libs/igraph.so':
? libRlapack.so: cannot open shared object file: No such file or directory

Perhaps it's better to get someone with a Fedora 20 that understand better than I do debugging package installation, since I'm not far abusing your patience.

Eric.

  
  


  


      

    

    

      
      

        


  

        

      Martin Morgan
    

    

      
      #
    

  


  

      
On 05/06/2014 02:12 PM, E N wrote:

            

      
      
      
    

        
The problem here (and in each of the following examples) is that the R package 
fBasics was installed with an R from before your recent update; the fBasics 
package is looking for libRblas.so, but the fedora package manager has removed 
this so it is no longer present. The solution is to re-install fBasics (and 
mculst and igraph).

These packages are installed in a system directory, so updating requires sudo.

Likely other packages are in a similar state; this R command

   xx = installed.packages()
   table(xx[,Built"])

might point to packages installed with different R versions than your current 
version (embarrassingly, I get

2.14.1  3.1.0  3.2.0
      2    568      6

indicating 2 packages were installed with a previous version of R and 6 with a 
latter version than the one I'm actually using -- R 3.1.0). The offenders are

   xx[xx[,"Built"] != "3.1.0",]

this test would not be sufficient for identifying problem packages.

Martin

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      E N
    

    

      
      #
    

  


  

      
Your answers are amazing! Now I have a bunch of packages to re-install:

xx <- installed.packages()
table(xx[, "Built"])
yy <- xx[xx[, "Built"] != "3.1.0", "Package"]
length(yy)
[1] 103

That's make it for my night! I'll do the upgrade tomorrow, hoping I won't be back on the mail list despite your kind warning it may not be the end. Once again, thank you so much!

Eric.