Compilation .h introuvable

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour à tous
J'ai un problème avec mon programme.
Lors de la compilation, mes 3 fichiers .h ne sont pas trouvés.

L'arborescence est la suivante :
-pcms_api
--ocilib.h
--pcmi_api.h
--premium
---common
----include
------pcms_event.h
---events
----autorisationBrancheProduit
-----user_supplied.c
-----makefile

donc dans mon fichier user_supplied.c j'ai bien inclus les 3 fichiers
Code:

1 2 3 4 5 #include "pcms_api.h" #include "pcms_event.h" #include "ocilib.h"
Mon makefile est le suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 CC=gcc CFLAGS=-W -Wall -ansi -pedantic EXEC=user_supplied all: $(EXEC) user_supplied: user_supplied.o $(CC) -o user_supplied user_supplied.o user_supplied.o: user_supplied.c $(CC) -o user_supplied.o -c user_supplied.c $(CFLAGS) clean: rm -rf *.o cleanall: clean rm -rf $(EXEC)
Qu'est-ce qui ne marche pas la dedans?!

Merci d'avance pour votre aide

24/09/2009, 16h15
Vincent Rogier

ben, les réportoires ./pcms_api et ./pcms_api/premium/common/include ne sont pas coonus du compilo (pas de declaration -Ixxxx) et je penses pas qu'ils soient inclus dans les sys includes...

Faut donc juste les inclure dans ton makefile
24/09/2009, 16h17
Grulim

ton .h n'est pas au même niveau que ton .c : le compilateur ne peut pas le trouver dans le répertoire courant (je suppose que tu es au même niveau que ton makefile) ou dans les repertoires d'include par défaut du compilo.

A vue de nez, il suffit de corriger les #include "XX.h" se comporte par #include "../../XX.h"

tu peux ajouter comme ca... Mais c'est pas tres propre ....
Mais il vaut mieux que les chemins soient dans le makefile que dans les declarations d'include...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 CC=gcc CFLAGS=-W -Wall -ansi -pedantic EXEC=user_supplied INCS= -I$../../../../pcms_api -I../../../common/include all: $(EXEC) user_supplied: user_supplied.o $(CC) -o user_supplied user_supplied.o user_supplied.o: user_supplied.c $(CC) $(INCS) $(CFLAGS) -o user_supplied.o -c user_supplied.c clean: rm -rf *.o cleanall: clean rm -rf $(EXEC)

24/09/2009, 16h36
Grulim

Citation:

Envoyé par Vincent Rogier

tu peux ajouter comme ca... Mais c'est pas tres propre ....
Mais il vaut mieux que les chemins soient dans le makefile que dans les declarations d'include...

[code]
CC=gcc
CFLAGS=-W -Wall -ansi -pedantic
EXEC=user_supplied
INCS= -I$../../../../pcms_api -I../../../common/include
...

C'est ce que je ferais pour une grosse API genre libxml2.

Pour un petit header à moi, j'utiliserais un include relatif.
Ca me semble plus lisible et permet d'un seul coup d'oeil dans le source de faire le lien...

Merci beaucoup pour vos réponses aussi rapides
J'ai donc changé mon makefile en ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 CC=gcc CFLAGS=-W -Wall -ansi -pedantic EXEC=user_supplied INCS= -I$../../../.. -I$../../../common/include all: $(EXEC) user_supplied: user_supplied.o $(CC) -o user_supplied user_supplied.o user_supplied.o: user_supplied.c $(CC) $(INCS) $(CFLAGS) -o user_supplied.o -c user_supplied.c clean: rm -rf *.o cleanall: clean rm -rf $(EXEC)
Ca a l'air de fonctionner mais le fichier pcms_api.h fournit par le client a l'air buggué! :p

25/09/2009, 00h14
souviron34

Citation:

Envoyé par michel.di

Ca a l'air de fonctionner mais le fichier pcms_api.h fournit par le client a l'air buggué! :p

Sans doute l'ordre des include, ou un define qui manque quelque part (dans les flags de compils sans doute..)).

Mais il faudrait en savoir plus sur ce qui a "l'air buggé"...
25/09/2009, 09h15
Vincent Rogier

Citation:

Envoyé par Grulim

C'est ce que je ferais pour une grosse API genre libxml2.

Pour un petit header à moi, j'utiliserais un include relatif.
Ca me semble plus lisible et permet d'un seul coup d'oeil dans le source de faire le lien...

sauf que :

-si ton fichier change de place
- ou que l'arborscence change
- ou que tu souhaite réutiliser ton header dans un autre projet

ben ta solution n'est pas viable.

Cela n'a rien a voir avec l'importance du projet...

le bug concernant l'api du client était un problème de commentaires. Il les mettait en // au lieu de /* */

Par contre j'ai un autre problème :
j'ai deux variables

Code:

1
2
3
 
char id_produit[128];
char id_version[512];

et je fais

Code:

1
2
3
 
id_produit = ptrObj->productId;
id_version = ptrObj->revision;

la structure étant la suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
typedef struct
{
int uid;
int objType;/* PCMS_ITEM or PCMS_PART */
/*or PCMS_CHDOC etc*/
int typeUid;
char typeName[PCMS_L_TYPE_NAME + 1];
char productId[PCMS_L_PRODUCT_ID + 1];
char objId[PCMS_L_CD_ID + 1];
char variant[PCMS_L_VARIANT + 1];
char revision[PCMS_L_REVISION + 1];
char description[PCMS_L_DESCRIPTION + 1];
char userName[PCMS_L_USER + 1];
char status[PCMS_L_STATUS + 1];
char dateTime[PCMS_L_DATE_TIME + 1];
char isExtracted;/* 'Y' = Yes, 'N' = No */
int noAttrs;/* The number of pcms_defined */
/* attributes for this object */
PcmsObjAttrStruct *attrs;
/* Pointer to the array of pcms_defined */
/*attributes*/
} PcmsObjStruct;

et le problème a la compilation est que les types ne sont pas compatibles!

merci pour votre aide

25/09/2009, 09h41
Grulim
Citation:

Envoyé par michel.di

le bug concernant l'api du client était un problème de commentaires. Il les mettait en // au lieu de /* */

c'est pourtant légal en C, non ?
Citation:
Envoyé par michel.di

Code:

1 2 3 id_produit = ptrObj->productId; id_version = ptrObj->revision;
Pour copier un tableau dans un autre tableau on utilise memcpy.
Comme les chaines sont des tableaux spécialisés (se terminant par un '\0'), on utilise strcpy (et en général, les fonction pour manipuler des chaine commence par str).
25/09/2009, 09h47
michel.di
Citation:

Envoyé par Grulim

c'est pourtant légal en C, non ?

Pour copier un tableau dans un autre tableau on utilise memcpy.
Comme les chaines sont des tableaux spécialisés (se terminant par un '\0'), on utilise strcpy (et en général, les fonction pour manipuler des chaine commence par str).

j'ai donc fait ça
Code:

1 2 3 strcpy(id_produit,ptrObj->productId); strcpy(id_version,ptrObj->revision);
mais j'ai toujours la même erreur : type incompatibles dans affectation
25/09/2009, 10h18
Grulim
Citation:
Envoyé par michel.di

j'ai donc fait ça

Code:

1 2 3 strcpy(id_produit,ptrObj->productId); strcpy(id_version,ptrObj->revision);

mais j'ai toujours la même erreur : type incompatibles dans affectation
C'est pas possible, c'est pas une affectation... 8O
à la limite, il pourrait te répondre que les types passées en paramètre à la fonction ne sont pas bons !
Quel est le 1er message d'erreur ?
25/09/2009, 10h34
michel.di

non c'est bon maintenant je n'ai plus l'erreur! :)
merci beaucoup!
25/09/2009, 11h10
souviron34

Citation:

Envoyé par Grulim

c'est pourtant légal en C, non ?

en C99 seulement...
25/09/2009, 11h11
michel.di

Il ne me reste plus qu'à faire fonctionner Ocilib maintenant! :)
Merci encore à vous

mon makefile est le suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
CC=gcc
CFLAGS=-W -Wall -ansi -pedantic
EXEC=user_supplied
INCS= -I$../../../.. -I$../../../common/include
 
all: $(EXEC)
 
user_supplied: user_supplied.o
	$(CC) -o user_supplied user_supplied.o
 
user_supplied.o: user_supplied.c
	$(CC) $(INCS) $(CFLAGS) -o user_supplied.o -c user_supplied.c 
 
clean:
	rm -rf *.o
 
cleanall: clean
	rm -rf $(EXEC)

Comment le lier a la librairie Ocilib?

25/09/2009, 11h48
philippe_21
Citation:

Envoyé par michel.di

mon makefile est le suivant :
Comment le lier a la librairie Ocilib?

Il te manque une variable LDFLAGS : exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 12 ... LDFLAGS=-lpthread -lncursesw ... all: $(EXEC) eos: $(OBJ) $(CC) -o $@ $^ $(LDFLAGS) %.o: %.c $(CC) -o $@ -c $< $(CFLAGS)

mon nouveau makefile est donc devenu :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
 
CC=gcc
CFLAGS=-W -Wall -ansi -pedantic
EXEC=user_supplied
INCS= -I$../../../.. -I$../../../common/include
OCILIB=-DOCI_IMPORT_LINKAGE -DOCI_CHARSET_UNICODE
LDFLAGS= -lclntsh -locilib
 
 
all: $(EXEC)
 
user_supplied: user_supplied.o
	$(CC) -o user_supplied user_supplied.o -L/$/u01/app/oracle/product/db10.2.0/lib -L/$/u01/app/serena/cm/pcms_api $(LDFLAGS)
 
user_supplied.o: user_supplied.c
	$(CC) $(INCS) $(CFLAGS) -o user_supplied.o -c user_supplied.c $(OCILIB)
 
clean:
	rm -rf *.o
 
cleanall: clean
	rm -rf $(EXEC)

L'erreur est la suivante :
/usr/bin/ld: ne peut trouver -locilib

25/09/2009, 14h49
Vincent Rogier

le repertoire ou est ocilib ne doit pas être connu du linker....

modifie le makefile avec:

LDFLAGS= -lclntsh %OCILIB_SHARED_LIB_PATH% -locilib
25/09/2009, 15h21
michel.di
Citation:

Envoyé par Vincent Rogier

le repertoire ou est ocilib ne doit pas être connu du linker....

modifie le makefile avec:

LDFLAGS= -lclntsh %OCILIB_SHARED_LIB_PATH% -locilib

et a la place de %OCILIB_SHARED_LIB_PATH% je dois mettre le chemin vers libclntsh.so?
Le problème est que je ne sais pas ou elle se situe et en faisant
Code:

1 2 find / -name 'libclntsh.so' -print
j'ai droit a permission non accordée sur pleins de dossiers et donc je ne vois pas le résultalt :(

Voir 40 message(s) de cette discussion en une page