Compatibilité SL3, SL4 et 64-bit
Table of Contents
L'environnement système d'exploitation et logiciels de base s'est considérablement diversifié sur les WNs de la grille. SL3 32-bit a été l'environnement standard pendant plusieurs années. Certains sites, dont GRIF, ont commencé à déployer des WNs utilisant SL4 en 32-bit ou 64-bit (en particulier le CE du LAL, grid10.lal.in2p3.fr, contient presque exclusivement des WNs SL4 64-bit).
Les frameworks maintenus par les expériences prennent généralement bien en compte ces différences. Par contre, cette diversité requiert quelques opérations spécifiques pour des logiciels développés en dehors de ces framewors. Cette page liste les principaux points, leur implémentation est dépendante de la méthode utilisée pour construire le logiciel (shell script, Makefile, CMT...).
SL3 vs. SL4
Les 2 principales différences de SL4 par rapport à SL3 vue des applications sont :
- Une nouvelle version de gcc/g++ (3.4 au lieu de 3.2) et de la glibc.
- Une nouvelle version de Python (2.3 au lieu de 2.2)
Concernant Python, cela ne doit pas avoir beaucoup d'impact à part un éventuel message signalant que la version de l'API Python a changé. Ce message se produit si on utilise des modules (extensions) Python implémentés sous la forme de librairie partagée.
Le changement de version de gcc/g++ a particulièrement un impact pour les applications qui dépendent de fonctionnalités dont l'implémentation a changé en 3.4 ou celles qui dépendent de libraries partagées construites avec la version 3.2 du compilateur (nécessitant donc une version différente de glibc). Pour résoudre ce problème sans reconstruire les dépendances, il faut forcer l'utilisation de gcc/g++ 3.2 en utilisant la commande gcc32 (g++32) au lieu de gcc (g++). Le suffixe 32 signifie 3.2 et non pas 32-bit.
Pour identifier la version de SL utilisée, il faut regarder le fichier /etc/redhat-release.
32-bit vs. 64-bit
Une machine installée avec SL 64-bit doit normalement offrir l'ensemble de l'environnement 32-bit qui permet l'exécution d'une application construite en 32-bit sans modification et la reconstruction des applications en 32-bit.
L'impact du 64-bit concerne :
- Le compilateur gcc/g++
- Python (et plus généralement tous les langages interprétés pouvant avoir des modules d'extensions implémentés sous la forme de librairie partagée, comme Perl)
On peut identifier si le WN utilise une version 64-bit de SL avec la commande :
uname -i
Pour utiliser le compilateur en mode 32-bit au lieu de 64-bit (mode natif sur une machine 64-bit), il faut ajouter l'option -m32.
Remarque : il n'est pas possible d'utiliser une version 32-bit du compilateur sur une machine 64-bit. Il faut toujours utiliser la version correspondant à l'architecture.
Pour Python, si on utilise des modules 32-bit (sous forme de librairie partagée) dont il n'existe pas de version 64-bit (c'est en particulier le cas pour le middleware gLite, par exemple l'API LFC), il faut utiliser la version 32-bit de Python installée sous le nom python32. Une façon simple de faire est de tester si python32 existe et dans ce cas l'utiliser. Sinon utiliser python.
Pour Perl, il n'existe pas pour l'instant de workaround connu. Si on est dépendant de modules Perl 32-bit, il faut prendre contact avec le site.
