librairie manquante depuis mise à jour Ubuntu 16.04 LTS Fermé

Question

Bonjour,

depuis la mise à jour Ubuntu 16.04 LTS je ne peux plus lancer le logiciel freefem en mpi, j'ai recompilé freefem mais j'ai toujours des librairies manquantes:

load error : parms_FreeFem 	 fail : dlerror : libmpi_f77.so.1: cannot open shared object file: No such file or directorylist  prefix: './' '/usr/local/lib/ff++/3.46/lib/mpi/' list  suffix : '' , '.so' 

Je ne suis pas du tout à l'aise avec les installation/compilation et manipulation de librairies. Quelqu'un peut il m'aider svp?

Merci!

mamiemando · Answer

Bonjour,

Version 1

Vu que cette librairie semble, vu son chemin, avoir été compilée manuellement, as-tu essayé de recompiler cette librairie et ton programme ?

Version 2 (conseillée)

freefem existe sous forme de paquet, donc le mieux serait simplement de l'installer via la logithèque ou apt-get, une fois les dépôts universe ajouté à tes sources logicielles :
https://packages.ubuntu.com/yakkety/freefem

1) Active les dépôts universe
http://computriks.com/fr/activer-depot-universe-ubuntu

2) Lance une mise à jour via la logithèque et installe freefem. Version en ligne de commandes :

sudo apt-get updatesudo apt-get install freefem

Bonne chance

mamiemando · Answer

Si freefem est installé, alors pourquoi y a-t'il des bouts dans /usr/local ? En théorie les dépendances du paquets devraient suffire à son fonctionnement.

Concernant ton erreur de linkage, est ce que libmpi_f77 existe quelque part sur ton disque dur ? (en théorie dans /lib, /usr/lib ou /usr/local/lib) ?

ls -l /lib/libmpi_f77*ls -l /usr/lib/libmpi_f77*ls -l /usr/local/lib/libmpi_f77*

Si ce n'est pas le cas ça explique ton erreur de linkage. Si la librairie est présente dans un autre répertoire, indique moi lequel.

Bonne chance

mamiemando · Answer

Bonjour,

Pardon pour la réponse qui suit, qui est un peu longue, mais qui est importante pour que tu partes sur de bonnes bases.

1) Quelques rappels importants sur linux
1.a) Paquets vs sources

Cela veut dire que lorsqu'un prog est installé il n'y a pas de bouts dans local? 

Non effectivement. Si ton programme est purement installé par des paquets, rien n'est sensé s'installer dans /usr/local. Si par contre, tu installes des programmes autrement (typiquement en récupérant des sources, en les compilant, et en les installant avec make install), alors des bouts seront installés dans /usr/local.

Linux fonctionne ainsi typiquement pour éviter des collisions entre des programmes installés via le gestionnaire de paquets et ceux installés autrement.

Pour le linkage j'ai déjà tenté de chercher libmpi_f77 de partout mais sans succès... J'ai demandé donc au développeur de me l'envoyer mais on m'a expliqué qu'il fallait que je reconfigure et recompile et réinstaller. 

Effectivement car de deux choses l'unes :

- soit le paquet a été installé avec des paquets, et si les mainteneurs ont bien fait leur travail, alors toutes les dépendances sont explicitées dans le paquet, et donc toutes les librairies requises pour lancer le programme sont également installées. Note que si par erreur tu venais à vouloir supprimer un tel paquet, alors en cascade, tout ce qui en dépend serait supprimé.

- soit le programme a été compilé manuellement (comme le laisse penser les bouts dans /usr/local), et dans ce cas là, il faut au préalable s'assurer que toutes les librairies nécessaire à la compilation de ton programme sont présentes. Note que ces librairies peuvent elles-mêmes être installées soit par des paquets, soit manuellement en compilant des sources.

Quoi qu'il en soit il est important de privilégier les installations par paquets autant que possible :
1) c'est plus facile à mettre en œuvre
2) ce qui est installé par des paquets est mis à jour quand tu mets à jour ton système (en fait, mettre à jour son linux signifie mettre à jour les paquets installés)
3) c'est plus facile à désinstaller
4) en cas de soucis, tu es dans un contexte "propre" et tu peux éventuellement remonter des bugs si quelque chose cloche.

1.b) Miroirs et dépôts additionnel

Le seul cas où tu installes "manuellement" (sources + make install), c'est si les dépôts ne fournissent pas le logiciel dont tu as besoin. Pour déterminer si on est dans cette situation, il faut faire une recherche avec le site des paquets de ta distribution :
https://packages.ubuntu.com/fr/

En effet, apt-cache search ... ou apt-file search ... ne te permettront pas de savoir si un paquet existe ou non pour ton logiciel, puisqu'ils ne tiennent compte que des miroirs que tu as configuré dans /etc/apt/sources.list. En outre quand tu es sous ubuntu, beaucoup de logiciels sont dans des dépôts qui ne sont pas activés par défaut (cf dépôts universe et multiverse). Ce genre de choses peut d'ailleurs arriver aussi sous debian (cf dépôts non-free et contrib).

Dans ton cas il s'agit de freefem. Une petite recherche et on a ça :
https://packages.ubuntu.com/search?keywords=freefem&searchon=names&suite=xenial&section=all

On voit dans les paquets qu'il y un paquet freefem, c'est celui qui nous intéresse.
https://packages.ubuntu.com/xenial/freefem

On voit sur cette page deux choses : les releases ubuntu pour lesquelles le paquet existe. Tout va bien tu es en xenial et il existe. Et on voit surtout Paquet : freefem (3.5.8-5.1ubuntu1) [universe] dans le titre. Ce [universe] signifie que tu dois activer les dépôts universe (si ce n'est pas déjà fait) puis lancer :

sudo apt-get update

À partir de maintenant apt-cache search freefem devrait donner des résultats. On peut aussi en profiter pour réindexer les dépôts avec apt-file si tu l'utilises :

sudo apt-file update

Par contre je déconseille l'ajout de dépôt ppa (si tu ne sais pas ce que c'est, tant mieux :p) ou sous debian, des dépôts multimedia, qui sont souvent sources de problèmes.

Ok, maintenant histoire de se mettre bien, une petite mise à jour :

sudo apt-get upgrade

Il est important de s'assurer que si tu lances cette commande, aucun paquet n'est "maintenu" (c'est-à-dire gelé dans un numéro de version, ce qui peut par la suite empêcher la mise à jour où l'installation de paquets).

1.c) Le PATH

Un truc important, c'est comment "linux" (ton shell en vrai) fait pour comprendre que quand tu lances la commande freefem, c'est tel exécutable qu'il faut lancer.

Eh bien c'est comme sous windows : une variable d'environnement, appelée PATH, détermine une liste de répertoire dans lesquels espérer trouver un exécutable. En effet sans path, on ne pourrait pas lancer ls (il faudrait lancer /bin/ls) ou ifconfig (il faudrait lancer /sbin/ifconfig) ce qui n'est pas très pratique.

Le PATH permet également d'avoir un comportement clair si un exécutable figure dans plusieurs répertoire "à exécutable" (/bin; /sbin, /usr/local/bin, /usr/local/sbin notamment), car il indique dans quel ordre les inspecter.

Si tu lances une commandes sans spécifier son chemin absolu (par exemple ls au lieu de /bin/ls), alors le shell regarde avec le PATH chaque répertoire dans l'ordre et s'arrête dès qu'il trouve un exécutable. S'il n'en trouve aucun, il dit un truc du genre "bash: command not found".

Si on regarde un PATH standard voici ce qu'il contient :

(mando@velvet) (~) $ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

On voit que /usr/local/bin est privilégié à /usr/bin. C'est assez normal : souvent quand on installe un programme manuellement c'est que celui fourni par les paquets n'est pas satisfaisant (s'il est installé). Du coup il est légitime de mettre les répertoire dans cet ordre.

Et maintenant nous avons toutes les billes pour faire un ...

2) ... retour à ton problème

Je suppose maintenant que tu es dans ce cas :
1) ta xenial est à complètement jour
2) le dépôt universe est activé et tu as fait un sudo apt-get update, conformément à ce qu'on a vu dans 1.b.
3) apt-cache search freefem trouve freefem et confirme ainsi que tout est ok.

Installons freefem via les paquets :

sudo apt-get install freefem

sudo apt-get install free

À ce stade tu as des bouts dans /usr/local/. En particulier, je pense que tu as un exécutable /usr/local/bin/freefem). À cause du PATH, si tu lances la commande freefem il va lancer en vrai /usr/local/bin/freefem (voir 1.c). Il y a fort à parier que d'ailleurs, si tu lances /usr/bin/freefem tout se passe bien :-)

Tu l'auras compris, il faut nettoyer les bouts qui traînent dans /usr/local qui n'ont plus raison d'être.

Première chose à noter, tout ce qui est installé dans /usr/local n'est jamais vital au système par définition du rôle de /usr/local, car tout le système est installé par des paquets, et est donc en dehors de ce dossier. Donc en gros, supprimer des fichiers de /usr/local ne cassera jamais ton système, au pire ça empêchera de lancer certains programme installés "manuellement". En outre, tu pourrais tout à fait supprimer cet exécutable (sudo rm /usr/local/bin/freefem) mais il resterait encore des "bouts" à nettoyer.

Donc la bonne approche, en supposant que le makefile que tu as utilisé à l'époque pour installer freefem est bien fait, au même titre qu'il y a une cible "install" (utilisée par sudo make install) il y a sans doute une cible uninstall :

cd /le/repertoire/des/sources/de/freefemsudo make uninstall

À présent, freefem sera résolu par le shell comme étant /usr/bin/freefem et le problème devrait alors être résolu.

Bonne chance

Librairie manquante depuis mise à jour Ubuntu 16.04 LTS

3 réponses

Discussions similaires