Salut à tous c'est encore moi,
Un truc que je ne comprends pas:
quand je compile un fichier sourc je tape cc <fich.c> -o <fich.exe>
donc avec cette commande le fichier source est compile et linke, je recupere un fichier executable. Bon jusque la c'est pas trop complique.
Mais quant je faits dans mon fichier source appel a la librairie  par curses.h un #include <curses.h> et que j'essaye d'utiliser des fonctions pour recuperer les caracteres d'echappement du terminal actif <tigetnum> ou de definir un type de terminal <setupterm> je suis contraint de taper la commande cc -o <fich.c> <fich.exe> -lncurses.
Je n'arrive meme pas a trouver cette librairie. Mais j'ai bien trouve la curses.h par contre.Je me doute bien qu'il ya quelque chose qui m'echappe au niveau du linkage.

et -lcurses ça donne quoi ?
 
Parce que soit on utilise curses.h et libcurses.a, soit on utilise ncurses.h et libncurses.a, non ?

ben a partir du momment ou c'est bien installé,
 
-L pour ajouter un chemin au linker
 
j'ai pas compris c'est quoi le probleme exactement ?

Si je ne met pas l'option -lncurses ça ne compile pas j'ai une erreur du genre  setupterm et les autres fonctions qui se rattachent normalement curses.h indefinies

Mais qu'est ce que vous entendez par bien installees, je n'arrive pas a situer la ncurses.h sur mon systeme.

Tu te mélanges là.
Si tu as comme ligne: #include <curses.h>
Alors il faut que tu remplaces ton "-lncurses" par "-lcurses".  
 
Si tu as un #include <ncurses.h>, alors dis le, et on regardera autre chose comme source de problème.
 
D'autre part, quel environnement et quel compilateur utilises-tu ?

ta bibliotheque en question ne se resume pas à un simple header
 
tu l'as installer comment ? ou c'est scenser etre deja installer ?
 

Oui c'est deja installe sur une machine HP avec un UNIX

ben lance la commande adequate (en fonctipon de ce que ta dis Lam's) et balance les messages d'erreurs

Excusez j'ai saute une reponse delam's
Jai un  compil assez ancien et j'ai bien fait un #include de curses.h pour faire mes tests je me suis appuyer sur une doc linux. Dans l'immediat je ne peux pas relancer la commande mais voici le petit bout de code:
 
 
#include<stdio.h>
#include<term.h>
#include<ncurses.h>/*ou <curses.h> j ai essaye les deux*/
int main()
{
int lins,cols;
setupterm(NULL,filen(stdout),(int*)0);
lins=tigetnum("lines" );
cols=tigetnum("cols" );
printf("\nnombres de lignes:%`\nnombres de cols:%d\n",lins,cols);
}

#include<stdio.h>  
#include<term.h>  
#include<ncurses.h>/*ou <curses.h> j ai essaye les deux*/  
int main()  
{  
int lins,cols;  
setupterm(NULL,filen(stdout),(int*)0);  
lins=tigetnum("lines" );  
cols=tigetnum("cols" );  
printf("\nnombres de lignes:%d\nnombres de cols:%d\n",lins,cols);  
}

On reprend, en simplifiant outrageusement (que ESR me pardonne): curses est une (vieille) librairie propriétaire, payante, méchante. Des gentils hippies n'en voulaient pas, et ont donc crée ncurses. Qui est le New Curses, mais qui est compatible.
 
Donc, curses te donne un fichier curses.h qui est la déclaration de tes fonctions, et libcurses.a qui contient l'implémentation, et que tu utilises au link.
Et bien ncurses fait quelque chose de similaire : elle te donne ncurses.h et libncurses.a.
 
Donc, sous linux, il faut que tu inclues "ncurses.h" dans fich.c, et que tu fasses "-lncurses" au link.
Sous HP-UX, il faut que tu inclues "curses.h" et que tu utilises "-lcurses"

Sous unix ou trouve t on curses et ncurses pas sous include
ou alors il est cache ou lie a quelque chose d autre

$ uname -sr
HP-UX B.11.11
 
$ ls /usr/lib/libcurses*
libcurses.0   libcurses.1   libcurses.sl
 
$ ls /usr/include/curses*
/usr/include/curses.h

recopie le bout de code et essaye de le compiler avec
cc fich.c -o fich.exe tuvas voir que ça ne marche pas en tout cas pas sous Mandrke 9.0 ni sous HP UX

Ecoute, je ne peux pas plus pour toi. Je suis désolé. (Il y a juste filen qui n'est pas défini, je l'ai remplacé par 1 pour stdout, 0 étant stdin, et 2 stderr).  
 
-bash-2.05b$ cc -o lam lam.c -lcurses
-bash-2.05b$ ./lam
 
nombres de lignes:24
nombres de cols:80
-bash-2.05b$ cat lam.c
#include<stdio.h>  
#include<term.h>  
#include<curses.h>  
int main()  
{  
int lins,cols;  
setupterm(NULL, 1,(int*)0);  
lins=tigetnum("lines" );  
cols=tigetnum("cols" );  
printf("\nnombres de lignes:%d\nnombres de cols:%d\n",lins,cols);  
}

Oui ona les libcurses mais les .h pour les includes il n y en a pas?

Et ca compile comme du beurre sous Solaris 8...

J'ai l'impression que j'ai un probleme a comprendre la difference enre une librairie et un header

OK mais pourquoi est on oblige de rajouter l option -lcurses ou -lncurses?

le/les header c'est l'interface de ta bibliotheque
 
et c'est normal que ca marche pas  
$cc fich.c -o fich.exe  
 
et si tu donnais les messages d'erreurs

Relis calmement et doucement chaque mot que j'ai écris depuis le début du topic.
 
Si tu as des questions, on est là pour t'aider.  
 
Mais on est pas là pour te faire la lecture, ok ?

Ce que je ne comprend pas c'est que jusqu'a present je n'avais qu'a inclure le bon .h et de taper ma commande de compile et avec ce pe de fonction il me faut une option?

le code il tombe pas du ciel
 
-l pour dire au linker de faire les liens avec le code de la bibliotheque en question

Je ne peut pas vous redonner le mesage exact d erreur je ne suis pas a mon poste mais en reisant ce que m' a donne cris56 je commmence a y voir plus claire je sais je suis un peut collant et je m'en excuse et merci de votre aide.
Pour stdio.h on pas besoin de stipuler une option y a t il un moyen de faire en sorte de relier le header a la librairie?

Dites moi si j'ai bien ompris le mechanisme:
Dns le header on peut considerer qu'on a des definitions de fonctions mais que leurs codes sources se truvent dans une librairie.

Tu as compris, mais les termes sont faux.
 
On a des déclarations dans le header, et leur définitions (ie. le code compilé) dans les librairies.

Je vous remercie tous les deux de votre aide et en effet j'aurai du lire plus attentivement les reponses que vous m'avez fournies en effet dans mon esprit le code source etait le header ce qui n'en est rien.
Merci.
A+

Ok je vais faire attention a mon vocabulaire.Et y a t il un moyen d eviter d avoir a linker a chaque fois un header a une librairie

Non.  
 
Après tout, tu pourrais utiliser le même fichier header pour ton code Linux ou HP, mais tu ne voudrais pas utiliser la même librairie (puisque le code est incompatible).
 
D'autre part, tu peux vouloir utiliser le même header, mais utiliser des versions de la librairies différentes (une version optimisée, une version de debug, etc.).
 
Donc, c'est la reponsabilité de la doc de te dire quelles sont les libs à utilises. "man curses" ou man "ncurses".

Merci et quel patiente!!!!!! C'est vraiment un plaisir d'avoir eu a faire a vous deux .
Bon j'ai des obligations familliales.
Tchao A+

Ah, c'est l'heure du goûter... Vas-y, je ne voudrais pas que ta maman t'engueule à cause de nous.
 

pour moi non mais les gosses oui.Me revoila pour stdio.h stdlib.h il n'y a pas besoin de linker pourquoi?

Fichiers standards. Ils font partie du langage C, et sont fournis par le compilateur. Si tu fais "ldd fich.exe", tu verras que le compilateur a fait le lien avec libc.2 ou libc.so ou un truc comme ça...

en parlant de declaration, si tu oubli d'inclure un header (enfin si tu oubli de declarer une fonction), le compilo en genere une implicitement en fonction de comment tu l'utilise
 
c'est juste pour dire que c'est un truc caché et tres dangereux (si ca genere n'imp c'est à l'execution que ca plante), les warnings (quand ils sont activés) sont la pour te prevenir ("implicite declaration of..." )
 
enfin en gros c'est ca

Le truc dangereux c'est surtout que le compilo suppose que les fonctions non declarees renvoient un int.
 
Pour stdio et stdlib t'as pas besoin de linker parce que le compilo link implicitement avec la libc. Si tu veux faire du zele tu peux toujours lui dire -lc.

 
implicitement oui, ou par exemple si tu cache le type retour par un cast

Parce que la librairie standard du C est automatiquement liée lors de la compilation. Donc tu n'as pas à le demander.
 
En revanche, si tu utilises des fonctions prises dans des librairies particulières, style "libcurses.a" et/ou "libm.a", tu dois demander au compilateur d'inclure ces librairies lors de la compilation car il ne le fait pas automatiquement
=> cc fic.c -lcurses -lm -o fic.exe
ou bien
=> cc fic.c /usr/lib/libcurses.a /usr/lib/libm.a -o fic.exe
 
Il me semble que tu confondes header et librairie alors je vais essayer de résumer
Quand tu utilises une fonction quelconque, par exemple "fopen", cette fonction a besoin de paramètres et renvoie une valeur dans un certain type.
Afin que tu saches quels paramètres lui passer et quel type elle renvoie, le prototype de cette fonction est écrit dans un header (fichier ".h" ). Tu inclues ce header dans ton programme et à la compilation, le compilateur mémorise que "fopen" utilise en entrée deux "char *" et renvoie un "FILE *". La première partie de la compilation se passe bien car chaque fois que tu utilises "fopen" tu l'utilises comme il faut et le compilateur, syntaxiquement, ne trouve aucun problème.
Puis vient la seconde partie, l'édition des liens. Là, le compilateur a besoin de savoir comment fonctionne la fonction "fopen" et il va chercher le code correspondant dans les librairies que tu lui as indiqué. Sauf que pour la librairie standard, celle qui contient le code de "fopen", "malloc", "fgets", etc... le compilo va la chercher tout seul, sans que tu le lui dises. C'est programmé comme cela dans "cc".
Si, en plus de ces fonctions standard, il te vient l'idée faramineuse d'utiliser des fonctions moins standard, comme "sqrt" ou "pow" ou d'autres provenant de la librairie "/usr/lib/libm.a", tu dois alors inclure le header correspondant et aussi indiquer au compilateur d'utiliser cette librairie "/usr/lib/libm.a" ).
Enfin l'option "-l<qqchose>" est un raccourci vers "/ur/lib/libqqchose.a" d'où le "-lcurses" pour "/usr/lib/libcurses.a".

juste une chose Sve@r, c'est pas le compilateur qui  a besoin des binaires mais le linker (d'ou le -l...)  

Yes... mes mots ont dépassés mes paroles