Librairie gsl
Fermé
guadoc
Messages postés
70
Date d'inscription
mercredi 26 mai 2010
Statut
Membre
Dernière intervention
21 octobre 2011
-
26 mai 2010 à 23:48
mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 - 27 mai 2010 à 10:37
mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 - 27 mai 2010 à 10:37
A voir également:
- Librairie gsl
- Vulkan runtime librairie ✓ - Forum Logiciels
- C'est quoi une librairie en informatique - Forum Programmation
- Librairie statique vs dynamique ✓ - Forum Linux / Unix
- Logiciel librairie gratuit - Télécharger - Outils professionnels
- Z librairie - Accueil - Services en ligne
1 réponse
mamiemando
Messages postés
33346
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
8 novembre 2024
7 803
27 mai 2010 à 10:37
27 mai 2010 à 10:37
On commence par partir à la recherche du paquet :
Comme on veut faire du développement, le paquet finit par -dev. On l'installe :
Si on regarde un peu ce que cette librairie a dans le ventre avec la commande :
... on s'aperçoit que les headers proposés sont rangés dans le répertoire /usr/include/gsl. Ainsi il suffit d'inclure ces fichiers au moment opportun dans ton code. Exemple :
L'opérateur <...> va chercher dans les répertoires "standards", dont /usr/include fait partie sous linux. Note que si tes headers avaient été dans une autre arborescence, l'option -I ou -isystem de gcc/g++ permet de la préciser et ainsi de continuer à inclure tes headers sous la forme #include <gsl/...h>. Ici, on n'en a pas besoin.
Chaque module de ton programme se compile donc normalement :
(produit fichier1.o)
Regardons maintenant du côté des .so (librairie dynamique) et .a (librairie statique). Ta librairie propose les deux. Tout dépend si tu veux que ton exécutable soit standalone (compilé avec le .a qui sera copié dans ton exécutable) ou lié dynamiquement (ce qu'on utilise dynamiquement) avec le .so.
Encore une fois les .a et .so sont dans /usr/lib, un répertoire standard sous linux. Sinon on aurait eu besoin de l'option -L (même principe que -I). Donc encore une fois, on n'en a pas besoin.
Ainsi, la seule chose à faire est de passer le .so (option -l) ou le .a au moment de linker (dans la ligne de compilation qui produit ton binaire final, typiquement l'exécutable de l'application que tu développes). Comme la librairie s'appelle libgsl.so l'option à passer sera -lgsl. En admettant que ton programme se décompose en un fichier main.c et trois modules (fichier{1,2,3,}.{c,h})
Évidemment l'idéal est ensuite d'utiliser un makefile, car rapidement cela devient fastidieux ;-)
Bonne chance
apt-cache search gsl | grep lib
Comme on veut faire du développement, le paquet finit par -dev. On l'installe :
sudo aptitude update sudo aptitude safe-upgrade sudo aptitude install libgsl0-dev apt-file sudo apt-file update
Si on regarde un peu ce que cette librairie a dans le ventre avec la commande :
apt-file list libgsl0-dev
... on s'aperçoit que les headers proposés sont rangés dans le répertoire /usr/include/gsl. Ainsi il suffit d'inclure ces fichiers au moment opportun dans ton code. Exemple :
#include <gsl/gsl_vector_int.h>
L'opérateur <...> va chercher dans les répertoires "standards", dont /usr/include fait partie sous linux. Note que si tes headers avaient été dans une autre arborescence, l'option -I ou -isystem de gcc/g++ permet de la préciser et ainsi de continuer à inclure tes headers sous la forme #include <gsl/...h>. Ici, on n'en a pas besoin.
Chaque module de ton programme se compile donc normalement :
gcc -W -Wall -c fichier1.c
(produit fichier1.o)
Regardons maintenant du côté des .so (librairie dynamique) et .a (librairie statique). Ta librairie propose les deux. Tout dépend si tu veux que ton exécutable soit standalone (compilé avec le .a qui sera copié dans ton exécutable) ou lié dynamiquement (ce qu'on utilise dynamiquement) avec le .so.
Encore une fois les .a et .so sont dans /usr/lib, un répertoire standard sous linux. Sinon on aurait eu besoin de l'option -L (même principe que -I). Donc encore une fois, on n'en a pas besoin.
Ainsi, la seule chose à faire est de passer le .so (option -l) ou le .a au moment de linker (dans la ligne de compilation qui produit ton binaire final, typiquement l'exécutable de l'application que tu développes). Comme la librairie s'appelle libgsl.so l'option à passer sera -lgsl. En admettant que ton programme se décompose en un fichier main.c et trois modules (fichier{1,2,3,}.{c,h})
gcc -W -Wall -o mon_executable main.c fichier1.o fichier2.o fichier3.o -lgsl
Évidemment l'idéal est ensuite d'utiliser un makefile, car rapidement cela devient fastidieux ;-)
Bonne chance