R v3.4.0-2 unable to find libgfortran.so.3 on Arch

I was just on vacation for a month so am unable to say the exact point at which this happened, but R from the official Arch repos is now unable to start, citing

/usr/lib64/R/bin/exec/R: error while loading shared libraries: 
libgfortran.so.3: cannot open shared object file: No such file or directory

I thought that perhaps a symlink was improperly placed or destroyed, so I looked in /usr/lib to try to find it:

ls -halt /usr/lib/libgfortran.so.*

lrwxrwxrwx 1 root root   20 May 16 03:01 /usr/lib/libgfortran.so.4 -> libgfortran.so.4.0.0
-rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0

Has libfortran.so.3 been superseded by libgfortran.so.4 in Arch? If so, are there any possible workarounds for getting R to run with an older version?

pacman -Qi r

Name            : r
Version         : 3.4.0-2
Description     : Language and environment for statistical computing and graphics
Architecture    : x86_64
URL             : http://www.r-project.org/
Licenses        : GPL
Groups          : None
Provides        : None
Depends On      : blas  lapack  bzip2  libpng  libjpeg  libtiff  ncurses  pcre  readline  zlib  perl  gcc-libs  libxt  libxmu  pango  xz  desktop-file-utils  zip  unzip
Optional Deps   : tk: tcl/tk interface [installed]
                  texlive-bin: latex sty files [installed]
Required By     : None
Optional For    : graphviz
Conflicts With  : None
Replaces        : None
Installed Size  : 58.04 MiB
Packager        : Evangelos Foutras <[email protected]>
Build Date      : Tue 25 Apr 2017 05:04:31 AM EDT
Install Date    : Tue 20 Jun 2017 12:27:06 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Edit: If anyone else comes across this, the r-devel AUR correctly compiles and runs, so hopefully on the next version bump the issue will be resolved.

Solution 1:

Indeed, gfortran 7 bumps the ligfortran version to version 4. See http://gcc.1065356.n8.nabble.com/patch-fortran-PR77828-Linking-gfortran-7-compiled-program-with-libgfortran-of-5-x-allowed-but-crashes-td1311625.html It is not backwards compatible and some APIs have changed.

If you install an older version of gfortran you will get libgfortran.so.3. It is completely fine to have multiple versions in your system. Maybe there is a way how to rebuild R for version 4, but it will be possibly more work. See other answers how to rebuild the software https://stackoverflow.com/a/50744705/721644

Solution 2:

I work on a software named pyferret which needs libgfortran.so.3. I am running fedora 27 whose package manager installs gfortran 7 (A higher version) by default. This produces the shared object libgfortran.so.4 in /usr/lib64. Another Linux system running Ubuntu 16.04.3, however has libgfortran.so.3. I copied it to my system in ~/pkgs/libs and ran the application as

export LD_PRELOAD=/home/vasu/pkgs/libs/libgfortran.so.3:/home/vasu/pkgs/libs/libopenblas.so.0;pyferret

This worked without the above error.

Solution 3:

There are many packages in R dependent upon GCC Fortran. Some of those have not been updated to compile against the new GCC, while some package get updated that are dependent upon these, deldir and robustbase are two examples.

Check your warnings and are install any of the packages that fail to load then execute the upgrade.

Solution 4:

The problem may come from some AUR packages that haven't been rebuild after the GCC update. In my personal case, it was probably the package openblas-lapack that messed around (see https://bbs.archlinux.org/viewtopic.php?id=236900). So there might be no need to install any former version of GCC.

What I did was to:

1. update all my AUR packages (yaourt -Syua)
2. then rebuild R (pacman -S r)

and it worked again.

Solution 5:

This issue periodically occurs whenever libgfortran receives an incompatible soname bump, mostly because in the R world it is quite common for blas/lapack to be replaced by alternative implementations from the AUR.

The important thing to note here is that it is not actually R that has the error.

Minor disclaimer here: I'm speaking with my official Arch Linux bugwrangler hat on here, and this is how I would try to track down this sort of issue. (It's also how I check whether a bug report should be closed as invalid.)

Using my handy-dandy Arch Linux bugwrangler utility tool pkg-list-linked-libraries (it does what it says on the tin):

$ pkg-list-linked-libraries r libgfortran.so
==> checking linked libraries for r-3.5.1-2-x86_64.pkg.tar.xz ...
==> ERROR: No file in r-3.5.1-2-x86_64.pkg.tar.xz is linked to libgfortran.so

So, if it is not coming from R itself, where is it coming from? Using the tool lddtree (from pax-utils) to show not just the libraries needed by the executable (like ldd does), but to also show you, in tree format, why they are needed:

$ lddtree /usr/lib/R/bin/exec/R
/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
    libR.so => /usr/lib/R/lib/libR.so
        libblas.so.3 => /usr/lib/libblas.so.3
            libgfortran.so.5 => /usr/lib/libgfortran.so.5
                libquadmath.so.0 => /usr/lib/libquadmath.so.0
                libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
        libm.so.6 => /usr/lib/libm.so.6
        libreadline.so.7 => /usr/lib/libreadline.so.7
            libncursesw.so.6 => /usr/lib/libncursesw.so.6
        libpcre.so.1 => /usr/lib/libpcre.so.1
        liblzma.so.5 => /usr/lib/liblzma.so.5
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
        libz.so.1 => /usr/lib/libz.so.1
        libtirpc.so.3 => /usr/lib/libtirpc.so.3
            libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
                libkrb5support.so.0 => /usr/lib/libkrb5support.so.0
                libkeyutils.so.1 => /usr/lib/libkeyutils.so.1
                libresolv.so.2 => /usr/lib/libresolv.so.2
            libkrb5.so.3 => /usr/lib/libkrb5.so.3
            libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
            libcom_err.so.2 => /usr/lib/libcom_err.so.2
        librt.so.1 => /usr/lib/librt.so.1
        libdl.so.2 => /usr/lib/libdl.so.2
        libicuuc.so.62 => /usr/lib/libicuuc.so.62
            libicudata.so.62 => /usr/lib/libicudata.so.62
            libstdc++.so.6 => /usr/lib/libstdc++.so.6
        libicui18n.so.62 => /usr/lib/libicui18n.so.62
        libgomp.so.1 => /usr/lib/libgomp.so.1
    libpthread.so.0 => /usr/lib/libpthread.so.0
    libc.so.6 => /usr/lib/libc.so.6

The relevant bit here is the beginning:

/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
    libR.so => /usr/lib/R/lib/libR.so
        libblas.so.3 => /usr/lib/libblas.so.3
            libgfortran.so.5 => /usr/lib/libgfortran.so.5

And if I delete the libgfortran library because this is a testing chroot and I don't care what happens to it, I see:

/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
    libR.so => /usr/lib/R/lib/libR.so
        libblas.so.3 => /usr/lib/libblas.so.3
            libgfortran.so.5 => None

This clearly shows that it is libblas.so that has an error finding libgfortran.so, and from there you can check to see what pacman package owns the broken libblas.so -- and if it is truly an official repository package, then you can report a bug to get it fixed, if not, then now you know which AUR package to recompile yourself.