Bonjour,
 
j'ai un petit souci avec cette fonction.
Sur une exemple tout bete :
 

 
Et l'erreur retourné est :
 

 
Pourtant j'ai bien utilise la libraire math qui doit normalement contenir la fonction sqrt.
 
Renseignement :
compilateur : gcc 4.0.
linux : FC4 et mdv2006.
IDE : Kdevelop
 
 
Merci de votre aide

Il faut ajouter la bibliothèque mathématique au moment de l'édition de lien.
C'est-à-dire qu'il faut lier le fichier libm.so à ton programme pour que sqrt() soit une fonction reconnue.
 
Ca se fait avec l'option de compilation suivante : -lm
(-l = lier une bibliothèque, et "m" pour "libm" )

Merci beaucoup
 
mais quel ane je fais, en plus je le savais mais l'avais oublié,  
THX!!!

"m" pour "/usr/lib/libm.a"

Mmm...
 
"m" pour "libm.a"
 
"/usr/lib/" est géré par -L

.a ?

a comme 'archive'. C'est l'extension par défaut d'une bibliothèque générée par ar, l'archiveur (générateur de bibliothèque) de GCC.

ou libm.so

nan mais c'est bon, je suis pas idiot, seulement en 2006, à part si on compile en statique, on s'en sert plus des .a ... (ou alors pour des libs foireuses aux API/ABI trop instables)
 
edit: et puis http://people.redhat.com/~drepper/ [...] nking.html

Ca, c'est autre chose. en général, la libXXX.a n'est une couche intermédiaire qui gère l'accès à la biblibliothèque partagée libXXX.so (gère le dlopen(), les pointeurs de fonctions etc.)
 
Il y a deux façon de procéder :  
 
- la bibliothèque XXX statique :
 
tout le code est dans le libXXX.a et il doit être lié à l'application de façon statique (évidemment, c'est gros et redondant, d'un autre coté, c'est autonome...)
 
- la bibliothèque XXX dynamique :
 
le code est dans libXXX.so qui est unique
la couche d'interface (dlopen(), pointeurs de fonctions) se trouve dans un petit libXXX.a généré automatiquement quand on génère le .so, et qui doit être lié à l'application.

Ok, mais dire "on ne se sert plus de .a", est une anerie, si je puis me permettre.  
 
Etant donné que les avantages apportés par les bibliothèques partagés sont indéniables, il est recommandé d'utiliser ce mécanisme. OK.
 
Mais les .a existent toujours et sont réduits à leur plus simple expression, tout simplement parce qu'un gros fénéant de codeur comme toi et moi n'a pas envie de se coltiner des dlopen() et des gestion d'interface à coup de pointeurs de fonctions, alors que ce code est généré automatiquement et placé dans le .a quand on crée une bibliothèque partagée .so ...
 
Je vois déjà le codeur lambda en train d'effacer tous les .a qui trainent sur son disque... et ça fout la trouille !
 

le ``.a`` c`est la roue de secours, un peu cn de la brûler...

 
Pour quel OS ? Quand je crée un DSO sous Linux, ça ne génère pas de .a. "La couche d'interface" est dans l'exécutable.

Personellement, j'ai tendance à ne pas prendre Drepper pour un âne quand il parle bibliothèque. Même si son avis tranché me surprends un peu ...

La raison pour laquelle je n'ai pas précisé l'extension du fichier, c'est que pour moi ce n'est pas l'option "-l" qui définit l'extension, mais le fait de lier statiquement ou dynamiquement. Du coup, pour moi le "-lm" signifie juste "lier le fichier libm", le chemin étant précisé par -L (ou $LD_LIBRARY_PATH), et l'extension par la méthode de liage.
 
Pour le reste, je préfère lier dynamiquement, pour la simple raison que je ne vois pas de justification à dupliquer le code sur tous les fichiers.
Néanmoins, je trouve que lier statiquement a des avantages. Le premier que je vois, c'est bêtement lors de l'utilisation d'une version "exotique" d'une bibliothèque, qui présente des incompatibilités avec ce qui est normalement installé/présent. Lier statiquement, dans ce cas, évite de se prendre le chou à configurer le serveur où sera installé l'usine à gaz (parce qu'on est d'accord, si ça arrive, c'est qu'on est en présence d'Une Mauvaise Chose©)

 
 
 
BIEN dit