"rpy2" fails in Enthought Canopy (conflicting with internal GFORTRAN libraries)

Question

I tried to install rpy2 on Enthought Canopy using pip (on Ubuntu 12.04). The package seems to install successfully but when I try to import it:

In [1]: from rpy2.rinterface._rinterface import *
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-e2e1fe174266> in <module>()
----> 1 from rpy2.rinterface._rinterface import *

/home/kayhan/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/rpy2-2.3.8-py2.7-linux-x86_64.egg/rpy2/rinterface/__init__.py in <module>()
     99 
    100 
--> 101 from rpy2.rinterface._rinterface import *
    102 
    103 

ImportError: /home/kayhan/Enthought/Canopy_64bit/User/bin/../lib/libgfortran.so.3: version `GFORTRAN_1.4' not found (required by /usr/lib/libblas.so.3gf)

Without this this package (rpy2), R_magic in ipython-note book does NOT work!

It seems that the rpy2 is linked to gfortran libraries of the system while Enthought tries to load its own FORTRAN libraries! Similar issue was reported here. LD_PRELOAD is a decent solution because what is the point of shipping Enthought FORTRAN libraries!?

It seems yet another Enthought FORTRAN libraries conflicting with GFORTRAN libraries in linux (Ubuntu)! Either the libraries shipping with Enthough are faulty or there is no decent way to resolve this conflict. Either way, it is not good to have such conflict over and over again for a distribution (Enthought) whose main focus is scientific computing!

Try to `ldd` the binaries to see which libraries they're linked to vs. libraries they're supposed to be linked to. — adrin, Jan 13 '14 at 13:22
I did that. It is linked to the GFORTRAN libraries of the system not that of Enthought but can I specify for the installer which libraries to linked to? — kayhan, Jan 14 '14 at 15:30
Sure you could, you need to set the library paths. Either through the `configure` input parameters or the `LD_LIBRARY_PATH` environment variable. Look [here](http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html) for more details. — adrin, Jan 14 '14 at 17:34

score 4 · Answer 1 · edited May 23 '17 at 12:34

I had the same error with libgfortran and libblas for a custom package. As you mentioned Canopy is using its own libgfortran.so.3, shadowing the one in the system or library path (seemingly required by blas). Here is a workaround that for this and similar issues, based on changing the libgfortran symlink in Canopy:

Navigate to the lib directory of Canopy:

cd ~/Enthought/Canopy_64bit/User/lib/

An ls -l *gfortran.so.3* should give you something like:

 libgfortran.so.3 -> libgfortran.so.3.0.0 
 libgfortran.so.3.0.0

(Optionally) make a backup of libgfortran.so.3 (if it's not a symlink like here):

mv libgfortran.so.3 libgfortran.so.3.bkp

Locate the system library, e.g.:

locate *gfortran.so.3* | grep /usr/lib

/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0

Make a symlink from the system to the lib

ln -s /usr/lib/x86_64-linux-gnu/libgfortran.so.3 .

Now an ls -l *gfortran.so.3* should give you:

  libgfortran.so.3 -> /usr/lib/x86_64-linux-gnu/libgfortran.so.3

Relevant SO post: libgfortran: version `GFORTRAN_1.4' not found

"rpy2" fails in Enthought Canopy (conflicting with internal GFORTRAN libraries)

1 Answers1