xgarreau.org : Librairies en c sous linux

Compilation de tous les binious

Bon, et bien, nous y voilà, on a tout ! Il ne nous reste plus qu'à tout mettre nesemble selon différentes méthodes. On va commencer par la méthode du projet unique, sans librairies.
Après ça, on va se faire une petite librairie statique, ensuite, on va mettre en place une librarie dynamique (ou shared object, .so chez les pingouins, .dll chez les défenestrés !)
On n'abordera toutefois pas le cas de la construction des dll car franchement, ce serait perdre du temps pour rien. Je suis pour laisser les gens qui n'ont que ça pour occupper leurs tristes journées générer et utiliser (de façon HYPER galère) les librairies dynamiques en envirronnement ouinouin. Ici, je pense que nous sommes entre gens sérieux, on développe donc sous linux, FreeBSD, solaris ou autres unix. Franchement, je m'excuse de sembler aussi méchant vis à vis de wintruc mais quand vous aurez comparé les qualités des deux systèmes (au moins en matière de support de développement), je suis presque sûr que vous penserez comme moi.

A la fin de cette série d'infos, je vous renverrai sur les bons coins pour utiliser les makefiles, ainsi que les merveilleux outils GNU que sont autoconf, autoscan, automake et leurs copains.

Sans librairies
Placez vous dans le répertoire du projet puis tapez ça dans la console :
gcc -o test test.c tri_a_bulles.c
Ceci génère un exécutable test que l'on lance, toujours en étant placé dans le répertoire de projet, en tapant :
./test
Avec librairies statiques
Placez vous dans le répertoire du projet puis tapez ça dans la console :
gcc -c test.c
Vous obtenez un objet binaire test.o. C'est une compilation sans édition de liens. Compilez de même la librairie en tapant :
gcc -c tri_a_bulles.c
Ce qui donne tri_a_bulles.o. Comme je l'ai déjà dit, si plusieurs fichiers composent la bibliothèque, on aurait tapé
gcc -c fic1.c fic2.c ...
Il faut ensuite créer la bibliothèque. Pour celà, tapez :
ar -q tri_a_bulles.a tri_a_bulles.o
S'il y avait eu plusieurs fichiers ... référez vous au pages man de ar. Regardez surtout les options a, q et c !
Ok, maintenant on lie le tout :
gcc -o test test.c tri_a_bulles.a
Petite précision, normalement, l'éditeur de liens GNU de linux c'est ld. Ceci dit, si ça marche avec gcc, on ne va pas se plaindre. Toutefois, dans le doute et pour en savoir plus, tapez man ld
On ne se laisse pas décourager pour autant et on exécute :
./test
C'est bizzare non ? Ca marche pareil. Bienvenue dans le monde du codage efficace ...
Avec librairies dynamiques
Placez vous dans le répertoire du projet puis tapez ça dans la console :
gcc -c test.c
Puis :
gcc -c tri_a_bulles.c
Jusque là, vous n'êtes pas perdus, c'est pareil ! Oui, mais, maintenant on génère la librairie dynamique :
gcc -o tri_a_bulles.so -shared tri_a_bulles.o
Puis on génère l'exécutable en lui disant qu'il fera appel à la librarie dynamique tri_a_bulles.so :
gcc -o test test.o tri_a_bulles.so
Puis content qu'on est, on exécute :
./test ./test: error in loading shared libraries: tri_a_bulles.so: cannot open shared object file: No such file or directory
Et oui, le bon des librairies partagées c'est qu'elles sont liées au moment de l'exécution. Or, les librairies partagées, le système va les chercher dans un répertoire contenu dans la variable d'environnement LD_LIBRARY_PATH. Et bien, par défaut le répertoire courant n'en fait pas partie ... C'est con ?
Non, pas tant que ça ! Et il y a des outils, là encore pour faciliter les choses ...
Tapez :
ldd ./test tri_a_bulles.so => not found libc.so.6 => /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Visiblement, il y a une couille !
Alors, soit vous copiez votre librairie dans les répertoires qui contiennent des librairies dynamiques (/usr/lib, /usr/i486-linux-libc5/lib ou /usr/X11R6/lib chez moi), vous trouverez ça dans le fichier /etc/ld.so.conf.
Ou alors ajouter votre répertoire à la variable en tapant
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
Dans les deux cas, vous obtiendrez le résultat attendu en tapant :
./test

Sans librairies
Placez vous dans le répertoire du projet puis tapez ça dans la console : gcc -o test test.c tri_a_bulles.c Ceci génère un exécutable test que l'on lance, toujours en étant placé dans le répertoire de projet, en tapant : ./test

Avec librairies statiques
Placez vous dans le répertoire du projet puis tapez ça dans la console : gcc -c test.c Vous obtenez un objet binaire test.o. C'est une compilation sans édition de liens. Compilez de même la librairie en tapant : gcc -c tri_a_bulles.c Ce qui donne tri_a_bulles.o. Comme je l'ai déjà dit, si plusieurs fichiers composent la bibliothèque, on aurait tapé gcc -c fic1.c fic2.c ... Il faut ensuite créer la bibliothèque. Pour celà, tapez : ar -q tri_a_bulles.a tri_a_bulles.o S'il y avait eu plusieurs fichiers ... référez vous au pages man de ar. Regardez surtout les options a, q et c ! Ok, maintenant on lie le tout : gcc -o test test.c tri_a_bulles.a Petite précision, normalement, l'éditeur de liens GNU de linux c'est ld. Ceci dit, si ça marche avec gcc, on ne va pas se plaindre. Toutefois, dans le doute et pour en savoir plus, tapez `man ld` On ne se laisse pas décourager pour autant et on exécute : ./test C'est bizzare non ? Ca marche pareil. Bienvenue dans le monde du codage efficace ...

Avec librairies dynamiques
Placez vous dans le répertoire du projet puis tapez ça dans la console : gcc -c test.c Puis : gcc -c tri_a_bulles.c Jusque là, vous n'êtes pas perdus, c'est pareil ! Oui, mais, maintenant on génère la librairie dynamique : gcc -o tri_a_bulles.so -shared tri_a_bulles.o Puis on génère l'exécutable en lui disant qu'il fera appel à la librarie dynamique tri_a_bulles.so : gcc -o test test.o tri_a_bulles.so Puis content qu'on est, on exécute : ./test ./test: error in loading shared libraries: tri_a_bulles.so: cannot open shared object file: No such file or directory Et oui, le bon des librairies partagées c'est qu'elles sont liées au moment de l'exécution. Or, les librairies partagées, le système va les chercher dans un répertoire contenu dans la variable d'environnement LD_LIBRARY_PATH. Et bien, par défaut le répertoire courant n'en fait pas partie ... C'est con ? Non, pas tant que ça ! Et il y a des outils, là encore pour faciliter les choses ... Tapez : ldd ./test tri_a_bulles.so => not found libc.so.6 => /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Visiblement, il y a une couille ! Alors, soit vous copiez votre librairie dans les répertoires qui contiennent des librairies dynamiques (/usr/lib, /usr/i486-linux-libc5/lib ou /usr/X11R6/lib chez moi), vous trouverez ça dans le fichier /etc/ld.so.conf. Ou alors ajouter votre répertoire à la variable en tapant `export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH` Dans les deux cas, vous obtiendrez le résultat attendu en tapant : ./test

Le pourquoi du comment ?!?!?!
Avec les libraries statiques :

Vous fournissez l'interface et maintenez le binaire.
Vous pouvez apportez les modifications (à condition de respecter l'interface) que vous voulez à la librarie MAIS :
Toute modification de librairie nécessite une réédition de lien, d'ou recompilation de l'exécutable !

Avec les libraries dynamiques :

Vous fournissez l'interface et maintenez le binaire.
Vous pouvez apportez les modifications (à condition de respecter l'interface) que vous voulez à la librarie.
En cas de modification, vous n'avez qu'à remplacer l'ancienne librairie par la nouvelle.

Notons que :

L'option -o nom sert à préciser le nom de l'exécutable résultant, ici test. Sinon, on obtient un binaire exécutable a.out.
L'option -c sert à compiler sans édition de liens.
Les extensions .a et .so n'ont rien de formel. Si vous voulez, dans un élan nostalgique, utiliser .lib et .dll ou .bite et .cul, vous avez le droit, vous êtes libres, vous êtes sous linux ...
Il est bon de taper dans sa console bien aimée : man gcc
Il est bon de taper dans sa console bien aimée : man ar
Il est bon de taper dans sa console bien aimée : man ld
ldd sert à connaître les dépendances dynamiques d'un exécutable.
On peut ajouter des chemins de recherche de librairies dynamiques dans la vairiable d'environnement LD_LIBRARY_PATH ou dans le fichier /etc/ld.so.conf.

J'allais oublier !!!
Normalement, le programme affiche un truc comme ça : xavier@Rooty Rep: tabLong $ ./test tableau[0] = 1613489603 tableau[1] = 866884903 tableau[2] = 295298324 tableau[3] = 1614953842 tableau[4] = 1111079167 tableau[5] = 950260573 tableau[6] = 901366332 tableau[7] = 745370511 tableau[8] = 2063084132 tableau[9] = 374329280 Taille du tableau : 10 Tableau après permutation des cases 2 et 8. tableau[0] = 1613489603 tableau[1] = 866884903 tableau[2] = 2063084132 tableau[3] = 1614953842 tableau[4] = 1111079167 tableau[5] = 950260573 tableau[6] = 901366332 tableau[7] = 745370511 tableau[8] = 295298324 tableau[9] = 374329280 Tableau trié par la fonction de la librairie tableau[0] = 295298324 tableau[1] = 374329280 tableau[2] = 745370511 tableau[3] = 866884903 tableau[4] = 901366332 tableau[5] = 950260573 tableau[6] = 1111079167 tableau[7] = 1613489603 tableau[8] = 1614953842 tableau[9] = 2063084132 En scoop, vous apprenez que mon pc s'appelle Rooty (ce qui vient des Régulateurs de Bachman), que je me connecte sous le nom de xavier et que ce projet se trouve dans le répertoire tabLong. En outre le symbole $ précise que je ne suis qu'un simple utilisateur, le root ayant droit à un superbe #. Voilà !

J'allais oublier !!!

Normalement, le programme affiche un truc comme ça :

xavier@Rooty
Rep: tabLong
$ ./test
tableau[0] = 1613489603
tableau[1] = 866884903
tableau[2] = 295298324
tableau[3] = 1614953842
tableau[4] = 1111079167
tableau[5] = 950260573
tableau[6] = 901366332
tableau[7] = 745370511
tableau[8] = 2063084132
tableau[9] = 374329280

Taille du tableau : 10

Tableau après permutation des cases 2 et 8.
tableau[0] = 1613489603
tableau[1] = 866884903
tableau[2] = 2063084132
tableau[3] = 1614953842
tableau[4] = 1111079167
tableau[5] = 950260573
tableau[6] = 901366332
tableau[7] = 745370511
tableau[8] = 295298324
tableau[9] = 374329280

Tableau trié par la fonction de la librairie
tableau[0] = 295298324
tableau[1] = 374329280
tableau[2] = 745370511
tableau[3] = 866884903
tableau[4] = 901366332
tableau[5] = 950260573
tableau[6] = 1111079167
tableau[7] = 1613489603
tableau[8] = 1614953842
tableau[9] = 2063084132

En scoop, vous apprenez que mon pc s'appelle Rooty (ce qui vient des Régulateurs de Bachman), que je me connecte sous le nom de xavier et que ce projet se trouve dans le répertoire tabLong. En outre le symbole $ précise que je ne suis qu'un simple utilisateur, le root ayant droit à un superbe #. Voilà !

Pour ce qui est du renvoi sur la doc sur autoscan, autoconf, automake et leurs copains ce que j'ai trouvé de plus sympa, ce sont les infos pages du gnome-help-browser. Si vous ne l'avez pas installé, honte sur vous !

Pour trouver moults docs de developpement, voyez http://developer.gnome.org/. Il existe la même chose avec les libs kde sur http://developer.kde.org/. Il existe bien d'autres sources d'infos mais ce sont celles que je préfère.

Un petit conseil, si vous aimez le c, installez les librairies gtk+/gdk/glib/imlib/ORBit C'est le top.
Vous cherchez un environnement de développement ? Choisissez gIDE et glade si vous avez des affinités avec le projet et les librairies du projet gnome ou kdevelop pour affinités avec KDE.
Comme débogueur je dois dire que kdbg est génial, d'autant qu'il s'intègre via DCOP dans kdevelop. Mais xemacs est pas mal non plus et gdb aussi, le tout c'est de connaitre !
En bref, prenons ce qui existe de meilleur partout. Bienvenue dans linux et à bientôt pour de nouvelles aventures ...

Index

Auteur : Xavier GARREAU
Modifié le 22.09.2004

Compilation de tous les binious

Rechercher :