R v3.4.0-2 impossible de trouver libgfortran.so.3 sur Arch
Je suis juste en vacances depuis un mois, donc je suis incapable de dire exactement à quel moment cela s’est produit, mais R du compte rendu officiel d’Arch est maintenant incapable de commencer, citant
/usr/lib64/R/bin/exec/R: error while loading shared libraries:
libgfortran.so.3: cannot open shared object file: No such file or directory
Je pensais qu'un lien symbolique était peut-être mal placé ou détruit, alors j'ai regardé dans/usr/lib pour essayer de le trouver:
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
Est-ce que libfortran.so.3 a été remplacé par libgfortran.so.4 dans Arch? Si tel est le cas, existe-t-il des solutions de contournement pour que R soit exécuté avec une version plus ancienne?
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: Si quelqu'un d'autre rencontre cela, le fichier r-devel AUR est correctement compilé et exécuté. Par conséquent, si tout va bien, le problème sera résolu lors de la prochaine version bump.
En effet, gfortran 7 remplace la version de ligfortran par la version 4. Voir http://gcc.1065356.n8.nabble.com/patch-fortran-PR77828-Linking-gfortran-7-compiled-program-with-libgfortran-of -5-x-allowed-but-crashes-td1311625.html Il n'est pas compatible avec les versions antérieures et certaines API ont été modifiées.
Si vous installez une version plus ancienne de gfortran, vous aurez libgfortran.so.3. Il est tout à fait correct d'avoir plusieurs versions dans votre système. Il existe peut-être un moyen de reconstruire R pour la version 4, mais ce sera peut-être plus de travail. Voir autres réponses pour reconstruire le logiciel https://stackoverflow.com/a/50744705/721644
Je travaille sur un logiciel nommé pyferret qui nécessite libgfortran.so.3. J'utilise Fedora 27 dont le gestionnaire de paquets installe gfortran 7 (une version plus récente) par défaut. Cela produit l'objet partagé libgfortran.so.4 dans /usr/lib64. Un autre système Linux exécutant Ubuntu 16.04.3 a cependant libgfortran.so.3. Je l'ai copié sur mon système dans ~/pkgs/libs et j'ai lancé l'application en tant que
export LD_PRELOAD=/home/vasu/pkgs/libs/libgfortran.so.3:/home/vasu/pkgs/libs/libopenblas.so.0;pyferret
Cela a fonctionné sans l'erreur ci-dessus.
Le problème peut provenir de packages AUR qui n'ont pas été reconstruits après la mise à jour de GCC. Dans mon cas personnel, c’est probablement le paquetage openblas-lapack qui a déconné (voir https://bbs.archlinux.org/viewtopic.php?id=236900 ). Ainsi, il n’est peut-être pas nécessaire d’installer une version antérieure de GCC.
Ce que j'ai fait était de:
- mettre à jour tous mes paquets AUR (
yaourt -Syua) - puis reconstruisez R (
pacman -S r)
et cela a encore fonctionné.
Il existe de nombreux paquets dans R qui dépendent de GCC Fortran. Certains de ceux-ci n'ont pas été mis à jour pour être compilés avec le nouveau GCC, alors que certains paquetages mis à jour qui en dépendent, deldir et robustbase en sont deux exemples.
Vérifiez vos avertissements et installez tous les paquets dont le chargement échoue, puis exécutez la mise à niveau.
Je ne peux pas en dire plus sur Arch-Linux, mais plusieurs versions des bibliothèques gfortran sont disponibles sur le jeu standard de pensions inclus avec apt sur Ubuntu.
Lorsque je passais à 18.04 (LTS), je devais installer la version précédente à côté de la version 4 par défaut des bibliothèques.
Pour moi, la commande suivante a résolu ce problème:
Sudo apt-get install libgfortran3
La reconstruction de tous les paquets dans R peut ne pas résoudre le problème si votre paquet n'a pas été maintenu depuis longtemps, comme c'était mon cas.
Ce problème se produit périodiquement chaque fois que libgfortran reçoit une bosse soname incompatible, principalement parce que dans le monde R, il est assez courant de remplacer blas/lapack par des implémentations alternatives de AUR.
La chose importante à noter ici est que ce n’est pas réellement R qui a l’erreur.
Clause de non-responsabilité mineure: je suis en train de parler avec mon responsable officiel du dépanneur d’Arch Linux, et c’est de cette façon que je tenterais de dépister ce genre de problème. (C’est aussi comment je vérifie si un rapport de bogue doit être fermé comme invalide.)
En utilisant mon utilitaire bricoleur Archy bugwrangler pkg-list-linked-libraries (il fait ce qu’il dit sur l’étain):
$ 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
Donc, si cela ne vient pas de R elle-même, d'où vient-il? Utiliser l'outil lddtree (de pax-utils) pour montrer non seulement les bibliothèques nécessaires à l'exécutable (comme le fait ldd), mais aussi pour vous montrer, sous forme d'arborescence, pourquoi elles sont nécessaires:
$ 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
Le bit pertinent ici est le début:
/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
Et si je supprime la bibliothèque libgfortran parce que c'est un chroot de test et que je me fiche de ce qu'il advient de celui-ci, je vois:
/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
Cela montre clairement que c'est libblas.so qui trouve une erreur dans la recherche de libgfortran.so, et à partir de là, vous pouvez vérifier quel paquet pacman possède le libblas.so cassé - et si c'est vraiment un paquet de référentiel officiel, signaler un bogue pour le réparer, sinon, vous savez maintenant quel paquet AUR recompiler vous-même.