Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1952 connectés 

  FORUM HardWare.fr
  Programmation
  C

  [resolu]Fonction sqrt non reconnue...

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[resolu]Fonction sqrt non reconnue...

n°1335337
le fou
Forza Massallia
Posté le 30-03-2006 à 10:43:05  profilanswer
 

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

Code :
  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <math.h>
  4. void main (void)
  5. {
  6. double tmp=16;
  7. tmp = sqrt (tmp);
  8. printf("%f\n",tmp);
  9. }


 
Et l'erreur retourné est :
 

Citation :

[mathieu@Albatros ~]$ make essai
cc     essai.c   -o essai
/tmp/ccCCBP3p.o(.text+0x67): In function `solution':
essai.c: undefined reference to `sqrt'
collect2: ld a retourné 1 code d'état d'exécution
make: *** [essai] Erreur 1


 
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


Message édité par le fou le 30-03-2006 à 10:52:18

---------------
Celui qui sauve une vie, sauve l'humanité (Le Talmud) - Personne n'a plus grand amour que celui de donner sa vie pour ses amis (Jean XV, 13)
mood
Publicité
Posté le 30-03-2006 à 10:43:05  profilanswer
 

n°1335343
Elmoricq
Modérateur
Posté le 30-03-2006 à 10:48:09  profilanswer
 

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" )

Message cité 1 fois
Message édité par Elmoricq le 30-03-2006 à 10:48:59
n°1335349
le fou
Forza Massallia
Posté le 30-03-2006 à 10:51:57  profilanswer
 

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


---------------
Celui qui sauve une vie, sauve l'humanité (Le Talmud) - Personne n'a plus grand amour que celui de donner sa vie pour ses amis (Jean XV, 13)
n°1337108
Sve@r
Posté le 01-04-2006 à 19:31:56  profilanswer
 

Elmoricq a écrit :

"m" pour "libm"


"m" pour "/usr/lib/libm.a" [:aloy]

Message cité 2 fois
Message édité par Sve@r le 01-04-2006 à 19:32:41

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
n°1337112
Emmanuel D​elahaye
C is a sharp tool
Posté le 01-04-2006 à 19:50:21  profilanswer
 

Sve@r a écrit :

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


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


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1337193
Taz
bisounours-codeur
Posté le 01-04-2006 à 22:42:08  profilanswer
 

Sve@r a écrit :

"m" pour "/usr/lib/libm.a" [:aloy]


.a ?

n°1337197
Emmanuel D​elahaye
C is a sharp tool
Posté le 01-04-2006 à 22:49:29  profilanswer
 


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.


Message édité par Emmanuel Delahaye le 01-04-2006 à 22:50:14

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1337206
nargy
Posté le 01-04-2006 à 23:16:17  profilanswer
 
n°1337240
Taz
bisounours-codeur
Posté le 02-04-2006 à 09:23:03  profilanswer
 

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

Message cité 1 fois
Message édité par Taz le 02-04-2006 à 09:25:01
n°1337256
Emmanuel D​elahaye
C is a sharp tool
Posté le 02-04-2006 à 11:17:45  profilanswer
 


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.


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
mood
Publicité
Posté le 02-04-2006 à 11:17:45  profilanswer
 

n°1337259
Emmanuel D​elahaye
C is a sharp tool
Posté le 02-04-2006 à 11:24:34  profilanswer
 

Taz a écrit :

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


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 !
 


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
n°1337267
nargy
Posté le 02-04-2006 à 12:03:04  profilanswer
 

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

n°1337272
++fab
victime du syndrome IH
Posté le 02-04-2006 à 12:28:34  profilanswer
 

Emmanuel Delahaye a écrit :

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.)
[snip]
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.


 
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.

n°1337273
++fab
victime du syndrome IH
Posté le 02-04-2006 à 12:31:20  profilanswer
 

Emmanuel Delahaye a écrit :

Ok, mais dire "on ne se sert plus de .a", est une anerie, si je puis me permettre.


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

n°1340267
Elmoricq
Modérateur
Posté le 06-04-2006 à 09:52:02  profilanswer
 

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©)

n°1351891
big_dadi_f​at
Posté le 22-04-2006 à 17:07:08  profilanswer
 

Emmanuel Delahaye a écrit :

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.
 


 
 
 
BIEN dit  ;)


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  [resolu]Fonction sqrt non reconnue...

 

Sujets relatifs
Bouton abandonner en javascript [RESOLU][RESOLU] Comment dessiner une fenêtre?
[Résolu] Vider le cacheBloc Serveur comme nukeClan sur un site HTML [résolu]
[résolu][VBA]Afficher mon document Word[RESOLU] Petit script VBS
[ RESOLU ] chercher dans une chaine de caractère[VBA][Excel][Resolu]Connaitre le nombre de ligne d'une colonne
[Résolu] lire un morceau de fichier audio avec JMF[resolu] Listbox en paramètre d'une procédure
Plus de sujets relatifs à : [resolu]Fonction sqrt non reconnue...


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR