Discussion :

[VinsS]

Salut,

Dans cette ligne de commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
gcc -o dcraw -O4 dcraw.c -lm -ljasper -ljpeg -llcms

Que signifie -lm ?

Sans -lm la compilation se passe aussi bien mais je ne sais pas encore tester le résultat dans son entièreté.

[Médinoc]

Ça signifie lier à la bibliothèque mathématique. Sans ça, les fonctions de <math.h>, ainsi que certaines opérations sur les nombres à virgule flottante, sont inaccessibles.

[VinsS]

Ha oui, merci.

N'ayant pas de lib m.h dans mon /include ça m'intriguait.

[picodev]

Bonjour,
l'option -l sert lors de l'édition des liens à spécifier des bibliothèques dans lesquels l'éditeur de lien va (en gros) chercher le code des fonctions appelées pour les quelles il n'a pas encore de code. Si tu donnes l'option -lTRUC, l'éditeur de liens va chercher une bibliothèque se nommant libTRUC statique (.a) ou dynamique (.so) dans les répertoires par défaut. Tu peux spécifier d'autres répertoires à chercher avec l'option -L.
L'ordre dans le quel tu spécifies les bibliothèques est important, et c'est en général une bonne idée de mettre la libm à la fin.
Remarque que lorsque tu produis un exécutable il sera forcément lié à la libc (le -lc est implicite). On a tendance à dire que la libc est l'implémentation de la bibliothèque standard du C telle que définie par la norme (C11 en ce moment). Cela est vrai, mais en partie seulement. Les fonctions mathématiques font partie de la bibliothèque standard, mais, pour d'obscures et antiques raisons, elles sont souvent regroupées dans une bibliothèque à part nommée de facto libm.
C'est un choix d'implémentation que les dèv de la gnu libc ont pris. Il existe d'autres implémentations de la bibliothèque standard C comme musl, et les dèv de musl ont pris comme choix de tout placer dans la bibliothèque libc.
Il y a un effet similaire avec le standard POSIX, souvent intégré en grande partie dans la libc sauf pour les fonctions «real time» regroupées dans la librt.

[Médinoc]

N'ayant pas de lib m.h dans mon /include ça m'intriguait.

Il n'y a aucune correspondance forcée entre les fichiers d'en-tête et les bibliothèques:

• La bibliothèque standard du C (libc) définit des fonctions qui sont déclarés dans de nombreux fichiers d'en-tête différents.
• À l'inverse l'API Windows déclare pratiquement toutes ses fonctions en incluant <windows.h> (qui se charge d'inclure la plupart des nombreux autres fichiers d'en-tête Windows) alors qu'elles sont définies dans des bibliothèques diverses et variées.
• Mais il est vrai que beaucoup de bibliothèques sont livrées simplement avec un fichier d'en-tête du même nom.

L'ordre dans le quel tu spécifies les bibliothèques est important

C'est le cas de GCC et de la plupart des compilos pour les plate-formes unixoïdes, mais ce n'est pas le cas de Visual C++ pour Windows.
Cela a ses avantages et ses inconvénients: L'avantage est qu'on n'a pas à se soucier de l'ordre, l'inconvénient est qu'on ne peut pas avoir de fonctions "facultatives" dans le programme principal, qui défaultent sur la version de la bibliothèque si elles ne sont pas présentes (car Visual C++ donnera une erreur "duplicate symbol" s'il trouve la fonction est définie à la fois dans le programme principal et dans une bibliothèque; il protestera aussi si deux bibliothèques définissent la même fonction).