[Rd] problem with location of libraries 64-bit (opensuse)

Simon Urbanek simon.urbanek at r-project.org
Thu May 5 17:16:46 CEST 2011


On May 5, 2011, at 10:50 AM, Detlef Steuer wrote:

> 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):
> -----------------------
>> Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.  
>>>>> import rpy2.robjects as robjects  
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "/usr/local/lib64/python2.7/site-packages/rpy2/robjects/__init__.py",
>> line 12, in <module> import rpy2.rinterface as rinterface
>> File
>> "/usr/local/lib64/python2.7/site-packages/rpy2/rinterface/__init__.py",
>> line 66, in <module> from rpy2.rinterface.rinterface import *
>> ImportError: /usr/lib64/R/lib/libRlapack.so: undefined symbol:
>> _gfortran_concat_string
> ----------------------
> So there are difficulties with  lapack/fortran libs.

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

> An older version of apparently the same error can be found here:
> http://www.mail-archive.com/animov@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 .

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.


> ------
> 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
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list