Installation de OpenBLAS sur CentOS/Fedora

Question

Dans un projet Java, j'utilise matrix-toolkits-java (MTJ) pour une multiplication matricielle efficace. Cela repose sur netlib-java, qui repose à son tour sur une implémentation optimisée de BLAS et LAPACK installés sur la machine. Il recherche spécifiquement /usr/lib64/libblas.so.3 et /usr/lib64/liblapack.so.3 pour trouver ces bibliothèques.

Lors de l'installation blas et lapack via yum, nous obtenons des liens symboliques /usr/lib64/libblas.so.3 et /usr/lib64/liblapack.so.3 pointant vers les fichiers .so de la référence blas et lapack installé via Yum.

Maintenant, nous voulons utiliser des implémentations qui sont plus rapides que celles de référence, dans mon cas OpenBLAS. Indifférent de savoir si je compiler moi-même, ou l'installer via Yum, je me retrouve avec /usr/lib64/libopenblas-r0.2.18.so.

maintenant, selon aucun guide sur l'Internet que je suis censé remplacer les liens symboliques à la mise en œuvre de référence avec des liens symboliques à la mise en œuvre de OpenBLAS, de se retrouver avec quelque chose comme ceci:

libblas.so.3 -> libopenblas-r0.2.18.so 
liblapack.so.3 -> libopenblas-r0.2.18.so 

D'accord, je peux le faire cette! Je peux le faire avec ln, ou via alternatives. Et si je fais ça, mon code utilise heureusement le rapide OpenBLAS.

Cependant, lorsque ldconfig fonctionne mes liens symboliques géniaux ont disparu, ils sont remplacés par les installations de référence BLAS et LAPACK. Et puis mon logiciel est triste et lent à nouveau.

Donc ma question est, comment installer OpenBLAS sur CentOS/Fedora de telle sorte que l'exécution ldconfig ne le détruire? Je ne peux pas supprimer les packages blas et lapack, car les autres clients de l'hôte peuvent s'en remettre. Au contraire, je voudrais faire en quelque sorte le système d'exploitation comprendre que OpenBLAS est une alternative à blas et lapack.

Answer 1

This article propose l'installation openblas-compat via yum. Cela résout le problème pour moi. Après avoir installé le package blas par défaut, mon logiciel utilisait toujours OpenBLAS.

Answer 2

Je ne pense pas que ce comportement puisse être évité sans supprimer les implémentations de référence. Si vous devez reconstruire manuellement ld.so.cache, vous pouvez exécuter ldconfig -X pour éviter la mise à jour des liens.

à part que vous aurez très probablement de créer un script personnalisé pour restaurer les liens symboliques à openblas après ldconfig mis à jour les liens