Discussion :

[LaseLiep]

Bonjour,

Je suis sur un problème depuis po mal d'heures, je me permets donc de faire appel à vous.

Explication du problème :
J'ai un fichier tp.h (avec les proto de fonctions) ainsi que le fichier tp.o (ce que j'obtiens lors de la compilation de mon tp.c). Je cherche à tester les fonctions qu'il y a dans tp.h (le fichier tp.c ne se trouve pas dans le répertoire). Pour tester les fonctions, je crée donc un nouveau fichier test.c avec mes fonctions de test (qui testeront les fonctions du tp.c). Je n'oublie bien sûr pas d'inclure le fichier tp.h par un include.
Or quand je tape la commande pour générer mon .o (gcc -o test test.c), je me retrouve avec ceci afficher à l'écran :

fonction1
collect2: ld a retourné 1 code d'état d'exécution

(sachant que fonction1 est dans mon tp.h et la fonction permettant de tester ma fonction1 est dans test.c et se nomme test_fonction1)

Si qqn aurait une solution, je suis preneuse car je commence à désespérer.

[Nasky]

Ta ligne de compilation ne fait pas référence à tp.c. Or si les fonctions se trouvent dedans, le compilo ne pourra les trouver.

Nas'

[LaseLiep]

Oui mais j'ai le tp.o donc comme il est dans le répertoire, c'est po bon?
Ou sinon, je teste aussi avec les commandes :

gcc test.c
gcc test.o tp.o -o test

mais bon, à la première commande, il me met la même erreur et donc po de fichier test.o généré ...

[Jack_serious]

Oui mais j'ai le tp.o donc comme il est dans le répertoire, c'est po bon?
Ou sinon, je teste aussi avec les commandes :

gcc test.c
gcc test.o tp.o -o test

mais bon, à la première commande, il me met la même erreur et donc po de fichier test.o généré ...

$> man gcc

Si tu tape gcc test.c il va compiler et linker. Si tu veux compiler un fichier seul sans linker (par exemple si tu n'as pas de main(), que tu veux juste verifier la synthaxe, il faut taper

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$> gcc -c test.c tp.c

Ensuite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$> gcc -o test test.o tp.o

Si tu tape gcc test.c avec test.c un fichier qui ne contient pas de main() ou des appels a d'autres fonctions c'est sur que ce bon vieux compilo va raler.

[LaseLiep]

Dans mon fichier test.c, y a un main, donc de ce côté là, c'est bon.
Quand tu écris :

gcc -c test.c tp.c

je n'ai po accès à mon fichier tp.c mais juste au tp.o, donc ok, je peux faire gcc -c test.c, ça me crée un test.o mais ensuite, quand je fais la deuxième ligne de commande que tu as écrite, ça me met :

> gcc -o test test.o tp3.o
/usr/ucb/ld:
read_cur_obj_info: 'tp.o' is an ELF object, which is not supported
collect2: ld a retournÚ 1 code d'Útat d'exÚcution

???

[DaZumba]

je n'ai po accès à mon fichier tp.c mais juste au tp.o

read_cur_obj_info: 'tp.o' is an ELF object, which is not supported

ELF signifie Executable and Linking Format. C'est le format des fichiers executables et objets utilises sous Linux et certains Unix. J'imagine donc que tu as recupere un .o compile sous Linux ou Sun, et tu essaies de travailler sous Windows ou un Unix qui utilise un autre format de fichier (probablement COFF [Common Object File Format] ou XCOFF [Extended COFF]).

En general, les fichiers objets ne sont pas exportables sur une autre plateforme que celle ou ils ont ete crees. Il faut que tu recompiles tp.c pour la plateforme que tu utilises pour compiler le reste du programme. Si tu n'as pas tp.c, alors il n'y a pas de solution.

[LaseLiep]

J'ai trouvé la réponse à mon problème, si qqn a le même, ça peut toujours servir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc -o test tp.o tp.h test.c

Merci de vous être attarder dessus ^^

P.S. : Pour l'explication, bah je sais po pourquoi c'est ça, mais ça marche! Si qqn veut bien m'expliquer, je ne dirais po non!

[Médinoc]

tu devrais retirer le .h de la ligne de commande, je pense...

[LaseLiep]

Exact, j'ai enlevé le .h et ça me donne le même résultat! C'est parce que j'ai fait un #include "tp.h" dans mon .c que j'ai po besoin de le mettre en ligne de commande?

[Emmanuel Delahaye]

Exact, j'ai enlevé le .h et ça me donne le même résultat! C'est parce que j'ai fait un #include "tp.h" dans mon .c que j'ai po besoin de le mettre en ligne de commande?

Oui. Mais j'espère que le tp.h est bien une interface et non une poubelle pleine de définitions de fonctions...

[LaseLiep]

Bahhh, euhhh, qu'entends-tu par "poubelle pleine de définitions de fonctions", parce que j'ai bien peur que ce que j'ai, en est une, (aïe aïe aïe).

[Emmanuel Delahaye]

Bahhh, euhhh, qu'entends-tu par "poubelle pleine de définitions de fonctions", parce que j'ai bien peur que ce que j'ai, en est une, (aïe aïe aïe).

Conseils pour organiser son code :

http://emmanuel-delahaye.developpez.com/codage.htm

[LaseLiep]

En effet, mon .h était une "poubelle pleine de définitions de fonctions" ;p
Dernièrement, mes profs m'ont donné un fichier .h comme toi tu les appelles interfaces, et je me suis dit, c'est leur manière perso de présenter du code, mais en fait, par rapport au site que tu m'as mis, je vois que c'est une sorte de "norme". J'en prends note, mici ^^