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

Question

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.

Answer 1

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.