Comment gérer une pile glibc / gcc /… distincte (plus récente) en tant que non root sur Linux

Notre cluster de calcul exécute une très ancienne version de CentOS, avec un ancien noyau (2.6.18) et, bien sûr, d'anciennes bibliothèques et binaires. Parce que la mise à jour de l'ensemble nécessite beaucoup de travail sur tous les nœuds, ce n'est pas une option.

J'essaie de compiler et d'utiliser un programme qui nécessite C++11et donc des versions plus récentes de gcc(et / ou clang). Parce que je ne veux pas du tout jouer avec le système, je veux le faire en tant qu'utilisateur non root dans une arborescence de répertoires locale.

Le problème est que cela gccnécessite une version plus récente glibcque celle présente sur la ou les machines. Par conséquent, je dois conserver une version distincte et plus récente de glibcdans mon lib/arborescence locale , probablement comme décrit ici .

Où je suis perdu, comment "coder en dur" les chemins de mes bibliothèques locales dans tous les binaires requis, c'est-à-dire gcc, g++etc.? La définition de LD_LIBRARY_PATH sur mon lib/arborescence locale empêche tous les binaires système de fonctionner ( ELF file OS ABI invalid) car ils veulent utiliser mon nouveau libm.so/ libc.socontre lequel ils n'ont pas été compilés.

Donc, pour résumer: Quelle est la bonne façon de maintenir une nouvelle pile de développement local (contenant glibc, gccetc.) en parallèle à un ancien système sans déconner en tant que root?

Comme question secondaire: la définition de LD_LIBRARY_PATH est publiée comme solution partout dans SE lorsqu'il s'agit de séparer glibc. Pour moi, cela provoque les erreurs ci-dessus lorsque j'essaie d'exécuter un système binaire (comme ls). Comment venir? Ai-je fait quelque chose de mal ou est-ce le comportement souhaité?

— janoliver
source

Vous avez essentiellement trois options:

Utilisez un wrapper autour de vos bibliothèques, qui sera défini de LD_LIBRARY_PATHmanière appropriée, puis exécutez la bibliothèque souhaitée - quelque chose comme:
```
#!/bin/sh
export LD_LIBRARY_PATH="path/goes/here"
exec "$@"
```
lien avec -rpath( -Wl,rpath) qui ajoute le chemin de recherche pour l'éditeur de liens dynamique dans le binaire (voir aussi la réponse SO - il mentionne également le wrapper).
Vous n'aimerez pas lire celui-ci: mettez à jour votre cluster (notez l'accent mis sur "votre"). Cela devra se faire un jour ou l'autre, alors pourquoi pas aujourd'hui. "Pas une option" est un peu fort dans la plupart des cas. D'autres utilisateurs ont probablement les mêmes problèmes.

En ce qui concerne les anciens binaires ayant des problèmes - les binaires ont leur éditeur de liens dynamique préféré intégré. Et l'ancien éditeur de liens dynamiques ne comprend pas le nouvel ABI. Essayez d' appeler les binaires comme ceci: path/to/your/ld-linux-<arch>.so binary.

Construction de GCC: vous pouvez toujours essayer d'exporter CFLAGSdans l'environnement de construction de GCC - mais je suis sûr qu'ils se propagent. Les scripts de construction de diverses distributions peuvent vous donner quelques indices (par exemple: pour openSUSE, regardez autour de la ligne 1880 dans le fichier .spec ).

— peterph
source

Salut peterph, merci pour la réponse. Je préfère l'option 2. Cependant, comment coder en dur le rpath dans, par exemple, gcc, sans avoir à changer le Makefile etc.? Quant à la mise à jour du cluster: cela est bien sûr à notre ordre du jour, mais en ce moment trop de gens l'utilisent pour justifier des temps d'arrêt plus longs. De plus, pour la mettre à jour, nous allons embaucher à nouveau l'entreprise qui l'a créée à l'origine. Personne dans notre groupe n'a suffisamment de connaissances et d'expérience pour cela.

— janoliver

Pour GCC, voir la mise à jour de ma réponse. Pour la mise à niveau du cluster, ma recommandation personnelle est d'obtenir un gourou interne (ou au moins externe à long terme). C'est généralement moins cher et plus flexible à long terme que de l'externaliser complètement. L'avantage le plus important est d'obtenir les connaissances à la maison grâce à des interactions entre l'administrateur système et les utilisateurs.

— peterph

En tant que petit groupe de recherche dans le système scientifique allemand désespérément sous-financé, nous ne sommes malheureusement pas en mesure d'engager quelqu'un pour cette tâche ou d'investir nous-mêmes le temps. Vous avez peut-être raison, à long terme, cela pourrait être payant, mais en ce moment, les budgets sont trop limités pour quelque chose comme ça. C'est l'inconvénient de ne pas être dans une entreprise. ;)

— janoliver

Obtenez des étudiants IT / CS de votre université - un bon étudiant pourrait même être en mesure de l'utiliser pour sa thèse BSc / Msc. Et en ce qui concerne les finances: soyez heureux que vous soyez en Allemagne et non dans l'un de vos voisins orientaux (peut-être à l'exception de l'Autriche). :)

— peterph

Au lieu de passer -rpath( -Wl,rpath) à l'éditeur de liens, l'éditeur de liens ajoutera également les chemins de la LD_RUN_PATHvariable d'environnement au chemin de recherche

— rakslice