Bonjour,
Y-a-t'il moyen d'installer des bibliothèques C et C++ par conda, ou faut-il qu'elles soient installées sur le système par vos soins? Je cherche à compiler un logiciel qui a un certain nombre de dépendances qui semblent absentes (les deux premières me semblent assez standard, je suis peut-être passé à côté de quelque chose de trivial):
Merci d'avance,
A.
Bonjour,
Apparemment sur conda-forge au moins deux packages sont disponible et ont l'air de contenir les librairies dont vous avez besoins:
On peux les rajouter aux environnement gcc déjà existant, dites nous si ca vous conviendrez.
Merci, je peux essayer et je vous tiens au courant si j'arrive à compiler.
J'ai en effet l'impression que les lib système qui sont présentes sont venues avec le système de paquet de la distribution; c'est leur nombre (622) qui m'a fait penser à tort que vous préfériez ne pas gérer l'environnement de compilation avec conda.
Du coup, il me faudrait également:
https://anaconda.org/conda-forge/zlib
https://anaconda.org/conda-forge/libarchive
Merci d'avance,
A.
Du coup c'est en cours d'install pour les envs gcc 7.5.0, 8.4.0 et 9.3.0 : https://gitlab.com/ifb-elixirfr/cluster/tools/-/merge_requests/325
C'est pas plus mal d'avoir un lot de librairie standard directement dans les environnements gcc.
Merci, ça serait pratique.
Par contre, n'y a-t'il pas un problème d'environnement avec les modules gcc? Il semble que seul le gcc du système soit dans le chemin, même après avoir appelé module load gcc. Ça ne me semble pas très intuitif:
gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
module load load gcc/8.4.0
gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Pourtant, il est bien là:
x86_64-conda_cos6-linux-gnu-gcc --version
x86_64-conda_cos6-linux-gnu-gcc (crosstool-NG 1.24.0.131_87df0e6_dirty) 8.4.0
Alors que:
module load compilers
gcc --version
gcc (crosstool-NG 1.24.0.123_1667d2b) 7.5.0
Ce qui montre qu'il est possible de surcharger le gcc du système. Intuitivement, je m'attendrais aussi à un changement de version de gcc après avoir chargé le module, j'ai manqué quelque chose? Techniquement, l'environnement compilers propose un lien symbolique gcc -> x86_64-conda_cos6-linux-gnu-gcc dans /shared/software/miniconda/envs/compilers-1.0.4/bin , ce qui n'est pas le cas des environnemnts gcc.
En effet, lors des conda build, il faut utiliser les variables ad-hoc.
$ source activate gcc-8.4.0
$ echo ${CXX}
/shared/software/miniconda/envs/gcc-8.4.0/bin/x86_64-conda-linux-gnu-c++
$ echo ${GCC}
/shared/software/miniconda/envs/gcc-8.4.0/bin/x86_64-conda-linux-gnu-gcc
En effet, on pourrait rajouter compilers pour avoir les liens symboliques. (On va faire quelques tests et l'ajouter si ca marche bien avec tout les version de gcc).
A priori, tout les Makefile utilisent les variables ${GCC}, ${CFLAGS} ..., du coup, ça devrait être la bonne version de gcc qui est utilisé quand l'env est chargé.
Le souci, c'est que ces variables sont bien défini quand on charge l’environnement Conda (comme indiqué par Gildas) mais elles ne sont pas bien défini quand on fait un simple module load (On va devoir faire évoluer notre façon de générer les modules).
Bonjour, c'est bon, c'est compilé, merci beaucoup!
Il faut quand même mettre les mains dans le cambouis; voici ce que j'ai dû faire pour que ça passe, au cas où ça puisse servir à quelqu'un d'autre. Notez que c'est un Makefile maison; il y a peut-être moins de problèmes si on passe par un système de build complet (autotools ou cMake).
La définition canonique des compilos dans les Makefile (CC=gcc, CXX=g++, etc) ne fonctionne pas, puisqu'il faut à la place utiliser les variables systèmes. Le plus simple est probablement de faire CXX?=g++ etc, puisque ça garantit une certaine portabilité. L'alternative, c'est de mettre CC=x86_64-conda_cos6-linux-gnu-gcc , puisque x86_64-conda_cos6-linux-gnu-gcc est dans le PATH. De la même manière, il faut définir LDFLAGS := $(LDFLAGS) -lgsl etc en tête du Makefile. Notez que le chemin des bibliothèques (-L/shared/software/miniconda/...) est dans $LDFLAGS (je ne suis pas sûr qu'il existe une variable consensuelle pour ça, peut-être $LD_LIBRARY_PATH?).
Pour une raison un peu obscure, j'ai dû ajouter -no-pie aux LDFLAGS pour éviter une erreur, c'est peut-être à cause des librairies fournies par l'environnement, mais je ne suis pas sûr.
Il me semble y avoir un problème au niveau de la variable $LDFLAGS fournie par l'environnement: les options au linker sont en -Wl,-option et pas en -option. Il s'agit donc d'options à fournir au compilateur pour qu'il les passe au linker, et pas d'options à passer au linker directement. J'imagine qu'il y a plusieurs manières d'écrire un Makefile, dans le mien, le linker $LD est appelé explicitement, il ne prend donc pas les $LDFLAGS fournis. Il y a un workaround simple : il suffit de mettre LD=$(CXX) en tête du Makefile, pour qu'il passe par le compilo pour appeler le linker.