Salut,
[il semblerai que tu soit sous UNIX et peut-être LINUX]
Je connais pas la lib 'COV', mais le principe est le suivant :
dans un dossier include : les fichiers qui décrivent les classes
dans un dossier lib : les fichiers qui contiennent les classes compilées
Ces fichiers sont reconnaissables par des extension .a (bibliothèque statique)
ou .so (bibliothèque dynamique). Un de ces fichiers doit être fourni lors
de l'édition des liens (création de l'exécutable).
Tu trouve un fichier qui à soit le nom libxxxx.a ou libxxxx.so.
Il peut y en avoir plusieurs. Habituellement le xxxx.h correspond
au nom du fichier 'include'.
Tu rajouter -lxxxx à la ligne de compilation et plus précisément
d'édition de lien.
Exemple pour la lib qt.
dans le source c++ : #include <qt.h>
à l'édition de liens : g++ -o ... ... ... ... -lqt
Espérant que ça puisse t'aider.
..., I think Slackware sounds better than 'Microsoft,'
-- Patrick Volkerding - founder and maintainer of Slackware

Alors comment lui dire ou son ses librairie autrement que comme je l'ai fait, ou ai je oublié quelque chose ..

A noter : il y a redondance entre :
#include "/home/LIBCOV/include/cov.h"
(par contre tu a oublié le / du début...) et l'option
-I//home/LIBCOV/include/

Soit tu utilise le #include de ton code (avec le '/' au début), soit tu met :
#include "cov.h"
(Ce qui est pratique quand le répertoire d'install de la libcov est amené à changer, il suffit de paramétrer le makefile pour l'option -I, bref...)

Ensuite, l'option -L sert à spécifier où sont les biblis qui ne sont pas dans les répertoires standards (comme /usr/lib, etc... y'a forcément l'équivalent sous Win [NDMM : je viens de me rendre compte qu'on s'en fout, nous deux...]).

Mais il te manque -lcov, qui indique de lier l'éxécutable avec libcov (.so ou .a).

Si c'est libcov.so, soit tu met -static pour forcer une édition de lien statique (!! à l'augmentation de la taille de l'éxé), grâce à l'option -static,
soit tu paramètre LD_LIBRARY_PATH, l'option du chemin standard pour les biblios. Cela sert à indiquer des chemin supplémentaire pour les bibliothèques partagées (les fameuses DLL, terme plus "windowsien", Shared Library ou Shared Object (so) sous UNIX).
sous bash :
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/LIBCOV/lib/
(ou autre répertoire incluant libcov.so), pour paramètrer ce chemin.

Voilà, avec ça ton éxé devrait rouler !!!

(NB : quand tu as le mdp root, tu peux rajouter un chemin VRAIMENT par défaut en éditant /etc/ld.so.conf. En l'occurence le mien contient :
/usr/X11R6/lib
/usr/lib/qt3/lib
/usr/local/lib
Ensuite il est necessaire de faire un
# ldconfig
pour que ld (LoaDer, qui charge aussi les .so) prenne la modif en compte)

Voili violon !!

Merci a tout les deux ...
En effet, j'avais oublié le -lcov a la fin de ma ligne de compilation.
Et pour l'execution, je n'avais pas de variable $LD_LIBRARY_PATH

Merci, il me reste plus qu'a apprendre a utiliser cette librairie :-)

a+

Bonjour,
Je vous remrcie, je n'ai pas mal appris de vos contribution,
Toute fois, je n'ai pas tout compris il parait, car je n'arrive pas à faire l'édition de lien d'un programme,
Q1) la spécification des chemins des librairies avec -L se fait au moment de la compilation ou bien de l'edition de lien,
par exemple si je compile mon programme comme suis

gcc -c source.c -I$HOME/Appli/Include

http://www.developpez.com/ puis C/C++ tutoriel, gcc. j'ai pas trouver mieu pour l'instant malheuresement.
Q1 : ld source.o -lmediastreamer -L$HOME/aplli/lib
l'option -l indique quelle librairie utilisé. et -L le chemin. ld est le linker.
Q2 : file.a est une mauvaise librairie statique contenant file.o. En effet toute libraire doit commencer par lib, et finir par .a.
les autres, je ne sais pas trop, mais dans le lot, il y en a qui designent des librairies dynamique (non lié à la compil, mais à l'execution)
en fait, tu devrai avoir libfile.a pour la librairie faite à partir de file.o
l'interet d'une librairie (de ce que j'en ai compris) c'est de pouvoir mettre plusieurs .o dans un seul fichier que l'on peut lier par la suite. De plus on peut passer par dessus les fonctions contenue dans le .a
exemple, si tu fait ld source.o file.o -lfile
tu n'aura pas d'erreur, les fonction contenue dans file.o remplacerons celles contenue dans libfile.a Salutation !
Char Snipeur

Essai de rajouter -L./ dans ta ligne de link.
En fait, j'ai eu des problèmes similaire. selon que l'on utilise gcc g++ ou ld pour lier, j'ai l'impression que ce ne sont pas les même répoertoire de recherche par défaut. Salutation !
Char Snipeur

Tiens ca fait des années que je fais du c/c++ et j'ai jamais eu à utiliser ld sauf cas super spécifique. A ta place je ferais simplement un makefile. Crée un fichier Makefile contenant ceci (respecte bien les tabulations derriere les cibles !! (all: run: ...)):

CXX=g++
CXXFLAGS=-W -Wall -O2

SRC=\
plop1.cpp\
plop2.cpp\
plop3.cpp

OBJ=\
plop1.o\
plop2.o\
plop3.o

all: $(OBJ)
    $(CXX) $(CXXFLAGS) $(OBJ)  main_plop.cpp -o plop.exe

depend:
    g++ -MM $(SRC) > .dependfile

%.o:%.cpp;$(CXX) $(CXXFLAGS) -c $< -o $@

run:
    ./plop.exe

clean:
    rm -rf *.o .dependfile *.exe
    touch .dependfile

ifeq (.dependfile,$(wildcard .dependfile))
include .dependfile
endif

make depend 
make

make

make clean