Skip to content

problem with location of libraries 64-bit (opensuse)

5 messages · Simon Urbanek, Detlef Steuer, M. Edward (Ed) Borasky

Original
Detlef Steuer
# 
Dear list, 

there seems to be a problem with the standard location of R?s 64-bit libs
at least under openSUSE.

I had two user questions regarding the compilation of rpy2 for 64-bit systems.
Personally I don`t know rpy2 but maybe someone on this list can decide if
the mistake lies on R`s side or on rpy2?s side or in between.

R-devel is installed in these cases, I asked. Latest R-base or R-patched is used.

The following problem occurs (user report):

-----------------------
----------------------


So there are difficulties with  lapack/fortran libs.

An older version of apparently the same error can be found here:
http://www.mail-archive.com/animov at faunalia.it/msg00311.html

Another user reported the following:

----
After installing the R devel version with Yast on the 11.4 64 system there  
was a link at this location :

/usr/lib64/libRlapack.so

and the actual file was here :

/usr/lib64/R/lib/libRlapack.so


I compiled R from source :

./configure --prefix=/usr --enable-R-shlib
make
make install

The make install step did not copy the new *.so files to /usr/lib64/R/lib
therefore I manually copied the new libRlapack.so , libR.so and libRblas.so

After that the python rpy2 library loaded and all was ok.

I hope this will help you to identify this issue .
------

Because he had to manually copy over libs after installing from source maybe 
there is an easy improvement on the side of R`s installation routines? Some ldconfig call missing or something? 
Or is this an opensuse specific problem?

Any hint appreciated.

Detlef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20110505/ad6ce876/attachment.bin>
Simon Urbanek
# 
Detlef,
On May 5, 2011, at 10:50 AM, Detlef Steuer wrote:

            

      
      
      
    

        
Yes, libgfortran is not loaded. You'll have to look at ldd output to see why - see further down.

            

      
      
      
    

        
This shows that rpy2 doesn't setup up the environment correctly (see the R script for the necessary settings). libR* are NOT supposed to the in /usr/lib64 - it is a bad hack and very dangerous (programs may pick the incorrect R libraries). Given that the setup is already messed up it's hard to tell what causes the gfortran problem. I don't have any SuSE around (they all died out long time ago) but to illustrate how things are supposed to work let's have a look at Debian (R installed from sources):

Inside R/lib there are the internal R libraries, again, they are NOT supposed to be at the system level:
urbanek at ix:/usr/local/R/2.13/lib/amd64$ ls libR*
libRblas.so  libRlapack.so  libR.so

so use ldd to see what they load:

urbanek at ix:/usr/local/R/2.13/lib/amd64$ ldd libRlapack.so 
	linux-vdso.so.1 =>  (0x00007fff602fa000)
	libRblas.so => not found
	libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007fbc5c3b4000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fbc5c197000)
	libc.so.6 => /lib/libc.so.6 (0x00007fbc5be36000)
	librt.so.1 => /lib/librt.so.1 (0x00007fbc5bc2e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbc5c94d000)

urbanek at ix:/usr/local/R/2.13/lib/amd64$ ldd libRblas.so 
	linux-vdso.so.1 =>  (0x00007fff27bff000)
	libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f9662988000)
	libm.so.6 => /lib/libm.so.6 (0x00007f9662706000)
	libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f96624f8000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f96622dc000)
	libc.so.6 => /lib/libc.so.6 (0x00007f9661f7b000)
	librt.so.1 => /lib/librt.so.1 (0x00007f9661d72000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9662eb1000)

so as you see, lapack links to blas which in turn links to gfortran. So if you load lapack you'll get gfortran vis blas. In your setup you are missing the link to gfortran for one reason or another. So check your setup with ldd to see why. I think it's highly likely that rpy2 is to blame, because R itself would not run if the fault would be in R.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Detlef Steuer
    

    

      
      #
    

  


  

      
Simon,

thank you very much for the detailed answer.

            

      
      
      
    

        
Ok, this mess up is easily identified. In my spec file I link
$libdir/R/lib/libRblas.so to $libdir/libRblas.so and the same for libR
and liblapack. Hmm. It works that way for ages, I can`t even vaguely
remember when and why I introduced that. 
Now I`ve build  R-patched with these links removed. 
At least "here it works". May be that cures rpy2, too.

Thx again
Detlef

  
  


  


      

    

    

      
      

        


  

        

      M. Edward (Ed) Borasky
    

    

      
      #
    

  


  

      
I've got an openSUSE 11.4 machine using R-patched - do I need to
change anything?

On Thu, May 5, 2011 at 12:55 PM, Detlef Steuer

        
<detlef.steuer at hsu-hamburg.de> wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Detlef Steuer
    

    

      
      #
    

  


  

      
Short answer: No!

I`ll just change/improve the procedure R is built.
Download R-patched tomorrow and some internals a "ordinary" user won`t notice will be changed. 

Detlef

On Thu, 5 May 2011 17:09:30 -0700

        
"M. Edward (Ed) Borasky" <znmeb at borasky-research.net> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20110506/42167fe3/attachment.bin>