mise à niveau glibc 2.12 à 2.14 sur Redhat 6.8 pour travailler avec Tensorflow et Python

Question

Notre serveur fonctionne sur Redhat 6.8 et Anaconda Python 3.6.1 installé.

Nous avons essayé d'importer le module python: Keras/Tensorflow et avons découvert que nous devions mettre à jour Glibc de 2.12 à 2.14 pour que cela fonctionne.

Nous téléchargé et installé la glibc 2.14 que l'installation séparée selon les instructions de ce lien How to upgrade glibc from version 2.12 to 2.14 on CentOS?

Ensuite, nous avons essayé d'importer le module Keras dans l'interpréteur python Python, il nous donne l'erreur « Segmentation fault (core dumped) "et retourne à l'invite de commande du système d'exploitation. Avant d'installer la Glibc 2.14, cela nous donne une erreur Glibc 2.14 introuvable.

Voici le lien que nous avons suivi pour installer le Tensorflow depuis le début. https://www.tensorflow.org/install/install_linux#InstallingAnaconda

Quelqu'un sait-il comment résoudre ce problème?

Merci!

Answer 1

La réponse à laquelle vous avez lié est incorrecte. Vous pouvez installer une deuxième glibc, mais vous devez quand même la compiler avec --prefix=/usr (et l'installer en utilisant DESTDIR), et vous devez exécuter tous les programmes avec un invocation de linker explicite, similaire à ce que fait le script testrun.sh dans la racine de construction. Pour un premier essai, vous pouvez simplement exécuter votre programme binaire directement en utilisant testrun.sh, sans même installer glibc dans le répertoire de destination.

Le wiki glibc a testing instructions. Elles s'appliquent à l'exécution de votre propre application avec une glibc fraichement construite (mais non installée).

Si vous utilisez seulement LD_LIBRARY_PATH, vous obtiendrez des plantages aléatoires car l'éditeur de liens dynamique et le reste de la bibliothèque ne correspondent pas. Il y a quelques mises en garde concernant l'approche testrun.sh car elle ne fournit pas une isolation complète, mais donne généralement des résultats assez décents. Cependant, contrairement à l'approche LD_LIBRARY_PATH, elle ne s'étend pas automatiquement à tous les sous-programmes lancés par le processus exécuté sous l'autre glibc. Notez qu'il peut être plus facile de mettre à niveau vers Red Hat Enterprise Linux 7 dans ce cas (qui fournit la glibc 2.17 de la boîte).