Il est né ?
Vous êtes ici : xgarreau.org >> aide >> devel >> libclinux : Librairies en c sous linux
Version imprimable

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

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


Avec les libraries dynamiques :

Notons que :

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 ...


Précédent Index Suivant

a+

Auteur : Xavier GARREAU
Modifié le 22.09.2004

Rechercher :

Google
 
Web www.xgarreau.org