Installing software in your home directory/fr: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
No edit summary
No edit summary
 
(141 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<languages />
<languages />
La plupart des logiciels utilisés par les chercheurs universitaires sont disponibles gratuitement sur Internet. Vous pouvez demander à Calcul Canada s'installer de tels logiciels que vous pourrez ensuite utiliser avec la commande <code>module load</code> (voir [https://docs.computecanada.ca/wiki/Utiliser_des_modules Utiliser les modules]); pour ce faire, écrivez à [mailto:support@calculcanada.ca support@calculcanada.ca] en joignant l'adresse URL pour l'installation. Si les clauses de la licence et les exigences techniques le permettent, le logiciel sera habituellement disponible dans 24 à 48 heures ouvrables.
La plupart des logiciels utilisés en recherche sont disponibles gratuitement sur Internet. Vous pouvez nous demander d'installer des logiciels que vous pourrez ensuite utiliser avec la commande <code>module load</code> (voir [[Utiliser_des_modules|Utiliser les modules]]); pour ce faire, écrivez à [mailto:support@tech.alliancecan.ca support@tech.alliancecan.ca] en joignant l'adresse URL pour l'installation. Si les clauses de la licence et les exigences techniques le permettent, le logiciel sera habituellement disponible entre 24 et 48 heures ouvrables.


Vous avez le droit d'installer des logiciels dans votre propre espace projet ou dans votre espace ''home'', par exemple pour  
Vous avez le droit d'installer des logiciels dans votre propre espace /project ou dans votre espace /home, par exemple pour  
* apporter vous-même des modifications au code
* apporter vous-même des modifications au code,
* évaluer un produit avant le temps alloué pour l'installation par notre équipe (24 à 48 heures ouvrables).
* évaluer le logiciel rapidement.


'''Prenez connaissance des directives pour l'installation du logiciel.''' Il s'agit souvent des instructions décrites ci-après.
<b>Prenez connaissance des directives pour l'installation du logiciel.</b> Il s'agit souvent des instructions décrites ci-après.


== configure; make; make install ==
== configure; make; make install ==
{{Commandes|./configure
{{Commands|./configure
|make
|make
|make install}}
|make install}}
Cette syntaxe de commande est fréquemment utilisée, avec des variantes telles <code>cmake .</code> au lieu de <code>./configure</code> et <code>sudo make install</code> au lieu de <code>make install</code>.
Cette syntaxe de commande est fréquemment utilisée, avec des variantes telles <code>cmake .</code> au lieu de <code>./configure</code> et <code>sudo make install</code> au lieu de <code>make install</code>.


Ces instructions fonctionnent comme prévu à l'occasion, mais <code>make install</code> crée quelquefois un obstacle car le logiciel s'attend à pouvoir écrire dans <code>/usr/local</code> ou autre espace partagé du système de fichiers. La commande <code>sudo make install</code> causera toujours l'arrêt de la procédure parce que <code>sudo</code> exige les permissions d'administrateur (''root''). La solution consiste à placer un indicateur <code>--prefix</code> à l'étape <code>configure</code> pour que l'installation soit dirigée vers le répertoire de votre choix, par exemple
Ces instructions fonctionnent comme prévu à l'occasion, mais <code>make install</code> créent quelquefois un obstacle, car le logiciel s'attend à pouvoir écrire dans <code>/usr/local</code> ou dans un autre espace partagé du système de fichiers. La commande <code>sudo make install</code> causera toujours l'arrêt de la procédure parce que <code>sudo</code> exige les permissions d'administrateur (<i>root</i>). La solution consiste à placer un indicateur <code>--prefix</code> à l'étape <code>configure</code> pour que l'installation soit dirigée vers le répertoire de votre choix, par exemple
{{Commande|./configure --prefix{{=}}/my/project/directory/some-package && make && make install}}
{{Command|./configure --prefix{{=}}/my/project/directory/some-package && make && make install}}


Si d'autres erreurs surviennent, contactez [mailto:support@computecanada.ca support@calculcanada.ca]. Pour les détails, consultez les pages  [https://docs.computecanada.ca/wiki/Make/fr Make], [https://docs.computecanada.ca/wiki/Autotools/fr Autotools] et [https://docs.computecanada.ca/wiki/CMake/fr CMake].
Si d'autres erreurs surviennent, contactez [mailto:support@computecanada.ca support@calculcanada.ca]. Pour les détails, consultez les pages  [[Make/fr|Make]], [[Autotools/fr|Autotools]] et [[CMake/fr|CMake]].
 
==Utiliser les bibliothèques==
Le moyen le plus simple pour utiliser une bibliothèque est habituellement de charger d'abord le module correspondant avec
{{Command|module load library_name/x.y.z}}
 
Une fois le module chargé, vous pouvez modifier les liens établis au cours du processus de ''build'' pour inclure la bibliothèque, par exemple
{{Command|gcc -o my_prog file1.o file2.o -lnetcdf}}
pour lier avec la bibliothèque NetCDF.
 
Sur la ligne pour le lien, le nom de la bibliothèque doit être préfixé par <tt>-l</tt>; il s'agit d'un fichier de type <tt>.a</tt> ou <tt>.so</tt>. Vous trouverez dans la documentation relative à la bibliothèque le nom de ce fichier et l'ordre dans lequel les liens doivent être établis dans les cas où vous avez plusieurs de ces fichiers. Le module pour la bibliothèque doit être chargé pour effectuer le ''build'', mais aussi pour exécuter l'application compilée à l'aide de la bibliothèque.
 
Le module pour la bibliothèque doit être chargé pour effectuer le ''build'', mais aussi pour exécuter l'application compilée à l'aide de la bibliothèque.
 
Le chargement du module d'une bibliothèque configure les variables d'environnement <tt>CPATH</tt> et <tt>LIBRARY_PATH</tt> pour qu'elles pointent sur la bibliothèque elle-même et ses fichiers d’en-tête (voir [[Utiliser des modules]]). La plupart des compilateurs, dont [https://software.intel.com/en-us/node/522775 Intel] et [https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html GCC] peuvent traiter ces variables; aux étapes de compilation et de construction des liens, les compilateurs iront automatiquement aux bibliothèques indiquées par les variables d'environnement.
Ceci permet de facilement établir un lien avec une bibliothèque sans devoir en indiquer le chemin avec les options <tt>-I</tt> et <tt>-L</tt>. Si votre fichier ''make''- ou ''config-'' demande l'endroit spécifique où se trouve la bibliothèque avec <tt>-I</tt> et <tt>-L</tt>, vous pouvez habituellement omettre d’indiquer le chemin en laissant les lignes vides.
 
Dans certains cas cependant, particulièrement avec <tt>cmake</tt>, il peut être nécessaire d'indiquer de manière explicite la localisation de la bibliothèque fournie par le module. La solution préférée et la plus robuste est d'utiliser la variable d'environnement EasyBuild <tt>EBROOT...</tt> plutôt que d'entrer manuellement le chemin. Ceci permet de facilement utiliser différentes chaînes de compilation (''toolchains'') sans modifier les instructions de compilation, en plus de minimiser le risque de lier une bibliothèque non apparentée. Par exemple, pour indiquer la localisation de la bibliothèque GSL, l'option pour <tt>cmake</tt> pourrait ressembler à <tt>-DGSL_DIR=$EBROOTGSL</tt>. Les variables d'environnement <tt>EBROOT...</tt> utilisent la même syntaxe, soit <tt>EBROOT</tt> suivi par le nom du paquet, par exemple <tt>EBROOTGCC</tt>.


== BLAS/LAPACK et MKL ==
== BLAS/LAPACK et MKL ==
Pour plusieurs paquets logiciels, les librairies d'algèbre linéaire numérique BLAS (-lblas) et LAPACK (-llapack) doivent être disponibles, ce qui n'est pas le cas pour les grappes de Calcul Canada puisque ces librairies sont intégrées à [https://software.intel.com/en-us/mkl Math Kernel Library] (MKL) d'Intel. Si vous utilisez un des compilateurs Intel (par exemple ifort, icc ou icpc), la solution est simple : il suffit d'ajouter au compilateur l'indicateur -mkl=sequential  (sans parallélisation MKL interne) ou -mkl  (avec parallélisation) ainsi que les options d’édition des liens pour faire en sorte que MKL et BLAS/LAPACK soient utilisés. Pour plus d'information, voyez [https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-mkl-compiler-option Using the -mkl Compiler Option]. Avec les compilateurs autres que ceux d'Intel, par exemple ceux de la collection Gnu, vous devrez lister explicitement les librairies MKL à l'étape des liens; vous pouvez utiliser l'outil d'Intel pour construire la syntaxe (voir [https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor Intel MKL Link Line Advisor]).
Voyez notre page wiki [[BLAS and LAPACK/fr|BLAS et LAPACK]].


== apt-get et yum  ==
== apt-get et yum  ==
Si le logiciel fait appel à <code>apt-get</code> ou <code>yum</code>, l'installation ne fonctionnera probablement pas. Cherchez des instructions qui mentionnent ''to build from source'' ou contactez [mailto:support@computecanada.ca support@calculcanada.ca] pour de l'aide.
Si le logiciel fait appel à <code>apt-get</code> ou <code>yum</code>, il est peu probable que vous puissiez l'installer avec ces instructions. Repérez les instructions ''to build from source'' ou contactez le [mailto:support@computecanada.ca soutien technique].


== Paquets Python, R et Perl ==
== Paquets Python, R et Perl ==
Ces langages possèdent d'importantes librairies de modules et des outils de gestion des modules pour aisément installer les fichiers de tous types dans votre répertoire ''home''. Consultez les pages [https://docs.computecanada.ca/wiki/Python/fr Python], [https://docs.computecanada.ca/wiki/R/fr R] et [https://docs.computecanada.ca/wiki/Perl Perl] pour savoir si le paquet dont vous avez besoin est disponible;  autrement, vous pouvez l'installer par vous-même en suivant les directives sur chacune des pages.
Les langages Python, R, et Perl offrent d'importantes bibliothèques d'extensions; presque toutes peuvent être facilement installées dans votre répertoire /home. Consultez les pages [[Python/fr|Python]], [[R/fr|R]] et [[Perl/fr|Perl]] pour savoir si le paquet dont vous avez besoin est disponible; si ce n'est pas le cas, vous trouverez aussi dans cette documentation l'information nécessaire pour l’installer par vous-même.
 
==Installer des paquets binaires==
L'installation de binaires précompilés (tels que [https://conda.io/miniconda.html Miniconda]) dans votre espace /home pourrait générer une erreur comme  <code>/lib64/libc.so.6: version 'GLIBC_2.18' not found</code>. Le script <code>setrpaths.sh</code> peut souvent éliminer ce problème avec la syntaxe <code>setrpaths.sh --path path [--add_origin]</code> où ''path'' représente le répertoire dans lequel vous avez installé le logiciel. Le script fait en sorte que les binaires utilisent le bon interpréteur et trouvent les bibliothèques auxquelles ils sont dynamiquement liés, dans le bon répertoire. L'option <code>--add_origin</code> ajoute aussi $ORIGIN au RUNPATH, ce qui peut s'avérer utile si la bibliothèque est incapable de trouver d'autres bibliothèques dans le répertoire où elle est située.
 
Note :
* Certains fichiers d'archive comme <code>.jar</code> (Java) ou <code>.whl</code> ([https://pythonwheels.com/ Python wheels]) peuvent contenir des objets qui devront être corrigés. Le script <code>setrpaths.sh</code> extrait ces objets, les corrige et met à jour le fichier d'archive.
 
== Environnement logiciel ==
Le système de fichiers CVMFS (<i>shared software distribution system</i>) rend presque tous les logiciels disponibles sur les nouvelles grappes. Sous Linux, les logiciels seraient typiquement installés dans <code>/usr/bin</code>, <code>/usr/include</code> et ainsi de suite, alors que dans notre cas, ils sont installés de manière identique sur toutes les nouvelles grappes sous <code>/cvmfs/soft.computecanada.ca</code>.
 
Le module <code>gentoo/2020</code> est chargé par défaut et agit comme cœur pour la pile logicielle gérée par le gestionnaire de paquets Gentoo situé sous <code>/cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09</code>.
 
Indiquez ce chemin avec la variable d'environnement <code>$EBROOTGENTOO</code>. À cet endroit se trouvent tous les paquets usuels fournis dans un environnement Linux dont  <code>make</code>, <code>ls</code>, <code>cat</code>, <code>grep</code>. À la compilation d'un logiciel, le compilateur et l'éditeur de liens cherchent typiquement les fichiers d'en-tête et les bibliothèques à l'endroit approprié (avec les variables d'environnement <code>$CPATH</code> et <code>$LIBRARY_PATH</code> respectivement).
 
Cependant, dans le cas de certains logiciels, <code>/usr</code> est explicitement indiqué; si c'est le cas, la compilation s'arrête et vous devrez spécifier <code>$EBROOTGENTOO</code>. Il faudra quelquefois ajuster un Makefile, passer un indicateur <code>--with-</code> via le script de compilation ou éditer un fichier de configuration. Si vous ne savez pas comment procéder, contactez le [[Technical support/fr|soutien technique]].
 
De la même manière, si un paquet dépend d'une bibliothèque provenant d'un module autre que <code>gentoo</code>, vous devrez peut-être spécifier où se trouvent les fichiers d'en-tête et les bibliothèques du module. Ces autres modules ont aussi une variable d'environnement commençant par EBROOT et se terminant par le nom du module en majuscules. Par exemple, après avoir exécuté la commande <code>module load hdf5</code>, son installation se trouvera dans <code>$EBROOTHDF5</code>, ses fichiers d'en-tête dans <code>$EBROOTHDF5/include</code>, ses fichiers de bibliothèque dans <code>$EBROOTHDF5/lib</code> et ainsi de suite.


== The Compute Canada software stack ==
Si un fichier d'en-tête ou une bibliothèque habituellement offerts dans une distribution de type Linux par un RPM ou autre gestionnaire de paquets ne se trouvent ni par <code>gentoo</code>, ni par un autre module, veuillez nous en informer; nous pourrons très probablement l'ajouter.
Almost all software that is used on the new clusters is distributed centrally, using the CVMFS file system. What this means in practise is that this software is not installed under <code>/usr/bin</code>, <code>/usr/include</code>, and so on, as it would be in a Linux distribution, but instead somewhere under <code>/cvmfs/soft.computecanada.ca</code>, and is identical on all new clusters.


The core of this software stack is provided by the <code>nixpkgs/16.09</code> module, which is loaded by default. This software stack, internally managed using the Nix package manager, is located at <code>/cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09</code>. The environment variable <code>$EBROOTNIXPKGS</code> should be used to refer to this path.
'''Notes'''
Under this location you can find all of the common packages typically included with Linux distributions, for instance <code>make</code>, <code>ls</code>, <code>cat</code>, <code>grep</code>, and so on. Typically, when you compile some software, the compiler and linker will automatically look for header files and libraries in the right location (via the environment variables <code>$CPATH</code> and <code>$LIBRARY_PATH</code>, respectively).
Some software, however, has been hardcoded to look under <code>/usr</code>. If that is the case, the compilation will typically fail, and needs to be explicitly told about <code>$EBROOTNIXPKGS</code>. Sometimes that means adjusting a Makefile, sometimes it needs to be specified in a certain <code>--with-</code> flag for the configure script, or a configuration file needs to be edited. If you are not sure how to do this please do not hesitate to ask for help.


Similarly, if a package depends on a library that is provided by a module other than <code>nixpkgs</code>, you may need to provide the location of the header files and libraries of that module. The EBROOT convention applies to all modules, e.g. the HDF5 library is installed in <code>$EBROOTHDF5</code>, and its <code>include</code> and <code>lib</code> subdirectories once you <code>module load hdf5</code>.
* Tous les binaires sous <code>/cvmfs/soft.computecanada.ca</code> utilisent un RUNPATH; les répertoires des bibliothèques d'exécution desquels dépendent ces binaires sont placés dans le binaire. Il <b>n'est donc pas nécessaire</b> d'utiliser <code>$LD_LIBRARY_PATH</code>. En fait, <code>$LD_LIBRARY_PATH</code> a préséance sur le RUNPATH et cette variable d'environnement ne devrait pas se trouver dans des endroits comme <code>/usr/lib64</code> ou <code>$EBROOTGENTOO/lib</code>. Si vous procédez ainsi, plusieurs binaires ne fonctionneront pas.
* En dernier recours, utilisez <code>module --force purge</code> pour éliminer l'environnement CVMFS. Vous obtiendrez ainsi une installation CentOS-7 brute, sans modules. Ceci peut servir dans des cas spéciaux où vous compilez GCC par vous-même ou quand vous utilisez des chaînes d'outils de compilation comme [http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk MESA SDK]. Il ne serait nécessaire de purger des modules qu'à la compilation et ils peuvent être chargés à nouveau au lancement du logiciel.


If a header file or library that would usually be provided by an RPM or other package manager in a typical Linux distributon is neither present via <code>nixpkgs</code> or via another module, please let us know. Most likely it can be easily added to the existing stack.
== Compiler avec un nœud de calcul ==


Notes:
Dans la plupart des cas, vous pouvez compiler avec un nœud de connexion. Toutefois, si le code doit être développé à l'aide d'un nœud
* all binaries under <code>/cvmfs/soft.computecanada.ca</code> use what is called a RUNPATH, which means that the directories for the runtime libraries that these binaries depend on are put inside the binary. That means it is generally *not* necessary to use <code>$LD_LIBRARY_PATH</code>. In fact, <code>$LD_LIBRARY_PATH</code> overrides this runpath and you should '''not''' set that environment variable to locations such as <code>/usr/lib64</code> or <code>$EBROOTNIXPKGS/lib</code>. Many binaries will no longer work if you attempt this.
* avec un GPU, ou
* if you install precompiled binaries in your home directory (for example [https://conda.io/miniconda.html Miniconda]) they may fail using errors such as <code>/lib64/libc.so.6: version `GLIBC_2.18' not found</code>. Often such binaries can be patched using our <code>setrpaths.sh</code> script, using the syntax <code>setrpaths.sh --path path [--add_origin]</code> where path refers to the directory where you installed that software. This script will make sure that the binaries use the correct interpreter, and search for the libraries they are dynamically linked to in the correct folder. The option <code>--add_origin</code> will also add $ORIGIN to the RUNPATH. This is sometimes helpful if the library cannot find other libraries in the same folder as itself.
* avec un CPU Skylake,
* if all else fails you can use <code>module --force purge</code> to remove the CVMFS environment. You are then left with a bare-bones CentOS-7 installation without modules. This may help for special situations such as compiling GCC yourself or using custom toolchains such as the [http://www.astro.wisc.edu/~townsend/static.php?ref=mesasdk MESA SDK]. Purging modules would then '''only''' be necessary when you compile such software; the modules can be reloaded when running it.
vous devriez démarrer une [[Running jobs/fr#Tâches_interactives|tâche interactive]] dans un serveur qui possède le matériel approprié et compiler de cet endroit.

Latest revision as of 19:34, 15 July 2024

Other languages:

La plupart des logiciels utilisés en recherche sont disponibles gratuitement sur Internet. Vous pouvez nous demander d'installer des logiciels que vous pourrez ensuite utiliser avec la commande module load (voir Utiliser les modules); pour ce faire, écrivez à support@tech.alliancecan.ca en joignant l'adresse URL pour l'installation. Si les clauses de la licence et les exigences techniques le permettent, le logiciel sera habituellement disponible entre 24 et 48 heures ouvrables.

Vous avez le droit d'installer des logiciels dans votre propre espace /project ou dans votre espace /home, par exemple pour

  • apporter vous-même des modifications au code,
  • évaluer le logiciel rapidement.

Prenez connaissance des directives pour l'installation du logiciel. Il s'agit souvent des instructions décrites ci-après.

configure; make; make install

[name@server ~]$ ./configure
[name@server ~]$ make
[name@server ~]$ make install

Cette syntaxe de commande est fréquemment utilisée, avec des variantes telles cmake . au lieu de ./configure et sudo make install au lieu de make install.

Ces instructions fonctionnent comme prévu à l'occasion, mais make install créent quelquefois un obstacle, car le logiciel s'attend à pouvoir écrire dans /usr/local ou dans un autre espace partagé du système de fichiers. La commande sudo make install causera toujours l'arrêt de la procédure parce que sudo exige les permissions d'administrateur (root). La solution consiste à placer un indicateur --prefix à l'étape configure pour que l'installation soit dirigée vers le répertoire de votre choix, par exemple

Question.png
[name@server ~]$ ./configure --prefix=/my/project/directory/some-package && make && make install

Si d'autres erreurs surviennent, contactez support@calculcanada.ca. Pour les détails, consultez les pages Make, Autotools et CMake.

Utiliser les bibliothèques

Le moyen le plus simple pour utiliser une bibliothèque est habituellement de charger d'abord le module correspondant avec

Question.png
[name@server ~]$ module load library_name/x.y.z

Une fois le module chargé, vous pouvez modifier les liens établis au cours du processus de build pour inclure la bibliothèque, par exemple

Question.png
[name@server ~]$ gcc -o my_prog file1.o file2.o -lnetcdf

pour lier avec la bibliothèque NetCDF.

Sur la ligne pour le lien, le nom de la bibliothèque doit être préfixé par -l; il s'agit d'un fichier de type .a ou .so. Vous trouverez dans la documentation relative à la bibliothèque le nom de ce fichier et l'ordre dans lequel les liens doivent être établis dans les cas où vous avez plusieurs de ces fichiers. Le module pour la bibliothèque doit être chargé pour effectuer le build, mais aussi pour exécuter l'application compilée à l'aide de la bibliothèque.

Le module pour la bibliothèque doit être chargé pour effectuer le build, mais aussi pour exécuter l'application compilée à l'aide de la bibliothèque.

Le chargement du module d'une bibliothèque configure les variables d'environnement CPATH et LIBRARY_PATH pour qu'elles pointent sur la bibliothèque elle-même et ses fichiers d’en-tête (voir Utiliser des modules). La plupart des compilateurs, dont Intel et GCC peuvent traiter ces variables; aux étapes de compilation et de construction des liens, les compilateurs iront automatiquement aux bibliothèques indiquées par les variables d'environnement. Ceci permet de facilement établir un lien avec une bibliothèque sans devoir en indiquer le chemin avec les options -I et -L. Si votre fichier make- ou config- demande l'endroit spécifique où se trouve la bibliothèque avec -I et -L, vous pouvez habituellement omettre d’indiquer le chemin en laissant les lignes vides.

Dans certains cas cependant, particulièrement avec cmake, il peut être nécessaire d'indiquer de manière explicite la localisation de la bibliothèque fournie par le module. La solution préférée et la plus robuste est d'utiliser la variable d'environnement EasyBuild EBROOT... plutôt que d'entrer manuellement le chemin. Ceci permet de facilement utiliser différentes chaînes de compilation (toolchains) sans modifier les instructions de compilation, en plus de minimiser le risque de lier une bibliothèque non apparentée. Par exemple, pour indiquer la localisation de la bibliothèque GSL, l'option pour cmake pourrait ressembler à -DGSL_DIR=$EBROOTGSL. Les variables d'environnement EBROOT... utilisent la même syntaxe, soit EBROOT suivi par le nom du paquet, par exemple EBROOTGCC.

BLAS/LAPACK et MKL

Voyez notre page wiki BLAS et LAPACK.

apt-get et yum

Si le logiciel fait appel à apt-get ou yum, il est peu probable que vous puissiez l'installer avec ces instructions. Repérez les instructions to build from source ou contactez le soutien technique.

Paquets Python, R et Perl

Les langages Python, R, et Perl offrent d'importantes bibliothèques d'extensions; presque toutes peuvent être facilement installées dans votre répertoire /home. Consultez les pages Python, R et Perl pour savoir si le paquet dont vous avez besoin est disponible; si ce n'est pas le cas, vous trouverez aussi dans cette documentation l'information nécessaire pour l’installer par vous-même.

Installer des paquets binaires

L'installation de binaires précompilés (tels que Miniconda) dans votre espace /home pourrait générer une erreur comme /lib64/libc.so.6: version 'GLIBC_2.18' not found. Le script setrpaths.sh peut souvent éliminer ce problème avec la syntaxe setrpaths.sh --path path [--add_origin]path représente le répertoire dans lequel vous avez installé le logiciel. Le script fait en sorte que les binaires utilisent le bon interpréteur et trouvent les bibliothèques auxquelles ils sont dynamiquement liés, dans le bon répertoire. L'option --add_origin ajoute aussi $ORIGIN au RUNPATH, ce qui peut s'avérer utile si la bibliothèque est incapable de trouver d'autres bibliothèques dans le répertoire où elle est située.

Note :

  • Certains fichiers d'archive comme .jar (Java) ou .whl (Python wheels) peuvent contenir des objets qui devront être corrigés. Le script setrpaths.sh extrait ces objets, les corrige et met à jour le fichier d'archive.

Environnement logiciel

Le système de fichiers CVMFS (shared software distribution system) rend presque tous les logiciels disponibles sur les nouvelles grappes. Sous Linux, les logiciels seraient typiquement installés dans /usr/bin, /usr/include et ainsi de suite, alors que dans notre cas, ils sont installés de manière identique sur toutes les nouvelles grappes sous /cvmfs/soft.computecanada.ca.

Le module gentoo/2020 est chargé par défaut et agit comme cœur pour la pile logicielle gérée par le gestionnaire de paquets Gentoo situé sous /cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09.

Indiquez ce chemin avec la variable d'environnement $EBROOTGENTOO. À cet endroit se trouvent tous les paquets usuels fournis dans un environnement Linux dont make, ls, cat, grep. À la compilation d'un logiciel, le compilateur et l'éditeur de liens cherchent typiquement les fichiers d'en-tête et les bibliothèques à l'endroit approprié (avec les variables d'environnement $CPATH et $LIBRARY_PATH respectivement).

Cependant, dans le cas de certains logiciels, /usr est explicitement indiqué; si c'est le cas, la compilation s'arrête et vous devrez spécifier $EBROOTGENTOO. Il faudra quelquefois ajuster un Makefile, passer un indicateur --with- via le script de compilation ou éditer un fichier de configuration. Si vous ne savez pas comment procéder, contactez le soutien technique.

De la même manière, si un paquet dépend d'une bibliothèque provenant d'un module autre que gentoo, vous devrez peut-être spécifier où se trouvent les fichiers d'en-tête et les bibliothèques du module. Ces autres modules ont aussi une variable d'environnement commençant par EBROOT et se terminant par le nom du module en majuscules. Par exemple, après avoir exécuté la commande module load hdf5, son installation se trouvera dans $EBROOTHDF5, ses fichiers d'en-tête dans $EBROOTHDF5/include, ses fichiers de bibliothèque dans $EBROOTHDF5/lib et ainsi de suite.

Si un fichier d'en-tête ou une bibliothèque habituellement offerts dans une distribution de type Linux par un RPM ou autre gestionnaire de paquets ne se trouvent ni par gentoo, ni par un autre module, veuillez nous en informer; nous pourrons très probablement l'ajouter.

Notes

  • Tous les binaires sous /cvmfs/soft.computecanada.ca utilisent un RUNPATH; les répertoires des bibliothèques d'exécution desquels dépendent ces binaires sont placés dans le binaire. Il n'est donc pas nécessaire d'utiliser $LD_LIBRARY_PATH. En fait, $LD_LIBRARY_PATH a préséance sur le RUNPATH et cette variable d'environnement ne devrait pas se trouver dans des endroits comme /usr/lib64 ou $EBROOTGENTOO/lib. Si vous procédez ainsi, plusieurs binaires ne fonctionneront pas.
  • En dernier recours, utilisez module --force purge pour éliminer l'environnement CVMFS. Vous obtiendrez ainsi une installation CentOS-7 brute, sans modules. Ceci peut servir dans des cas spéciaux où vous compilez GCC par vous-même ou quand vous utilisez des chaînes d'outils de compilation comme MESA SDK. Il ne serait nécessaire de purger des modules qu'à la compilation et ils peuvent être chargés à nouveau au lancement du logiciel.

Compiler avec un nœud de calcul

Dans la plupart des cas, vous pouvez compiler avec un nœud de connexion. Toutefois, si le code doit être développé à l'aide d'un nœud

  • avec un GPU, ou
  • avec un CPU Skylake,

vous devriez démarrer une tâche interactive dans un serveur qui possède le matériel approprié et compiler de cet endroit.