Discussion :

[Paul_Le_Heros]

Bonjour,

Je cherche à créer une librairie composée de plusieurs objets. Voici les commandes entrées à la console :

Code :

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

1
2
3
4
5
6
7
8
export C8_DEV=' -O0 -D_GNU_SOURCE -std=c99 -fstrict-aliasing -fwrapv -Wall -Wextra -g -iquote ./ -fmax-errors=10 '
 
gcc -fPIC -o obj/6303_modbu.o -c procs/6303/6303_modbu.c $C8_DEV
gcc -fPIC -o obj/6303_mocmd.o -c procs/6303/6303_mocmd.c $C8_DEV
gcc -fPIC -o obj/6303_emu.o -c procs/6303/6303_emu.c $C8_DEV
 
gcc -c -fPIC -o obj/lib_6303.o -o obj/6303_emu.o -o obj/6303_mocmd.o -o obj/6303_modbu.o procs/6303/6303_lib.c $C8_DEV
gcc -shared -o lib/lib_6303.o -o obj/lib_6303.so

Aucune des lignes 3, 4 et 5 ne génère d'erreur, et les objets sont bien créés. La ligne 7 ne génère pas d'erreur non plus, mais l'objet "obj/lib_6303.o" n'est pas créé, ce qui abouti évidemment à une erreur fatale à la ligne 8. L'erreur est probablement sous mon nez, mais je ne la trouve pas.

Je suppose que la personne susceptible de m'aider ne nécessite pas plus d'information. Cette personne aurait-elle une idée et le temps de m'aider avec une courte réponse, s'il lui plaît ?

Merci pour votre attention.

Edit : GNU C (SUSE Linux) version 4.8.5 (x86_64-suse-linux)

[Paul_Le_Heros]

L'option de compilation "-fPIC" est piégeante, mais ce n'est pas elle.
Même pas une direction dans laquelle regarder ?

[Jipété]

[...] ce qui aboutit évidemment à une erreur fatale à la ligne 8. L'erreur est probablement sous mon nez, [...]

Mais pas sous le nôtre, puisque tu ne nous la donnes pas...

Et comme , on n'ira pas loin...

[Paul_Le_Heros]

Code :

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

1
2
3
4
5
6
7
1 export C8_DEV=' -O0 … '
2 gcc -fPIC -o obj/6303_modbu.o -c procs/6303/6303_modbu.c $C8_DEV
3 gcc -fPIC -o obj/6303_mocmd.o -c procs/6303/6303_mocmd.c $C8_DEV
4 gcc -fPIC -o obj/6303_emu.o -c procs/6303/6303_emu.c $C8_DEV
5
6 gcc -fPIC -o obj/6303_lib.o -c procs/6303/6303_lib.c $C8_DEV
3 gcc -shared -fPIC -o obj/lib_6303.so obj/6303_modbu.o obj/6303_mocmd.o obj/6303_emu.o obj/6303_lib.o

Il semble bien que ce soit un problème de linker, puisque parmi les erreurs, j'ai :

Code :

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

1
2
3
4
…
    obj/6303_mocmd.o:./src/l8.h:195 : définitions multiples de « foo »
    obj/6303_modbu.o:./src/l8.h:195 : défini pour la première fois ici
…

Les messages ne sont guère plus clairs que ça, mais j'ai de quoi résoudre
mon problème.

Je conclue que c'est comme ça qu'on est supposé faire, c'est à dire ne "lier" les objets qu'au dernier moment… ce qui est finalement logique puisque le linker n'est invoqué qu'à ce moment-là (@Jipété_Le_Grand : comme quoi, pas besoin de plus d'info, ni de boule de cristal).

Merci pour votre attention et vos réponses.

[arcanum28]

et si tu nous donnais les éléments pour pouvoir test ca chez nous ?

[Paul_Le_Heros]

En fait j'étudiais "make", et je croyais (apparemment je me suis trompé) que le make "exécutait" récursivement le fichier "makefile" (ou autre nom suivant prorité / option). Mais non. Puisque make fonctionne correctement maintenant, j'en conclue qu'Il faut commencer par définir la règle de construction du fichier logiquement le "dernier" construit par l'humain (enfin, plutôt inhumaine, la bête). Ce que nous faisons habituellement est à peu près ceci :

Code :

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

1
2
3
4
5
6
1: écrire un ".h",
2: écrire le ".c" correspondant,
3: lancer gcc pour créer un ".o",
4: lancer gcc pour créer un ".so",
5: lancer gcc pour créer le "main.o" et enfin
6: lancer gcc (ou ld) pour lier "main.o" au ".so" et créer l'exécutable.

Mon fichier "makefile" fonctionne depuis que

Code :

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

1
2
3
a- j’ai défini la règle pour la construction de l’éxécutable (5: 6:),
b- j’ai défini la règle pour la construction du ".so" (4)
c- j’ai défini la règle pour la construction du ".o" (3)

et ce, dans cet ordre, donc sans respecter un ordre plus logique. EDIT J'avais pourtant noter cet ordre "inverse" dans un des tutos relatifs à make et consultables sur ce site.

Quelqu'un pour confirmer que je ne me trompe pas (encore) ?

[Paul_Le_Heros]

Si vous décompressez _3.tar.gz dans votre répertoire personnel, vous aurez créé un sous-répertoire contenant ceci :

~/_3/
├──bin/
├──lib/
├──obj/
├──src/
│ ├──lib_8.c
│ ├──lib_8.h
│ └──main.c
└──makefile

Pourquoi au premier lancement de "make -C ~/_3/↵", se passe-t-il aussi peu de choses ?

Vous pouvez construire ce fabuleux projet en saisissant "make -C ~/_3/ all↵" dans une console. J'ai ajouté l'impression en couleur pour faciliter le débogage.

Je ne comprend pas pourquoi, après avoir saisi "make -C ~/_3/↵", rien ne se passe alors que lib/lib_8.so a été supprimé (ou en ajoutant "--assume-new=lib/lib_8.so" à la commande). Quelqu'un saurait parler de la raison ?

Quelqu'un a déjà utilisé l'option -B (Unconditionally make all targets) ?

Merci pour l'attention que vous aurez portée à ce post.

[Paul_Le_Heros]

Jusqu'à maintenant, j'ai toujours fait sans make, même pour le projet en exemple. J'ai voulu passer à make maintenant, et chercher à comprendre sans abandonner en "jetant le bébé et l'eau du bain", comme jusqu'à maintenant. J'ai cru que mes fichiers "Makefile" ne fonctionnaient pas (de là à penser que make lui-même…). J'ai d'abord été perturbé par les messages de make, parce que ce qui suit le nom d'une règle, soit le nom résultat d'une compilation, et sont les dépendances, est une liste de règles et ou de fichiers. Or, les messages d'erreur de make ne parle que de RÈGLE tout en vous en indiquant son nom, et si ce nom est celui d'un fichier, vous pouvez être perdu.

J'avais l'impression que make ne fonctionnait pas bien avant que je ne me rende compte que c'était parce que les dépendances n'étaient pas complètes. Parlant du langage C, l'option "-MM" de gcc est très utile pour déterminer ces dépendances. J'ai écrit en php un petit utilitaire _help.tar.gz pas très pratique mais qui permet de visualiser ces dépendances. Noter que si un fichiers .o ou .so est généré à partir de la source "a" et avec des dépendances aux fichiers d0 et d1, et que les dépendances d'une règle ailleurs comprennent également d0 et d1, il est préférable de rendre cette dernière règle dépendante de la règle construisant le .o ou .so.
Par exemple, écrire :

Code :

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

1
2
3
4
lib/lib_dys.so: src/ThrDynStr.c src/ThrDynStr.h src/Vt-200.color.h
	@gcc …
lib/lib_symbo.so: src/Symbo.c src/Symbo.h src/Symbo_debug.c lib/lib_dys.so
	@gcc …

plutôt que:

Code :

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

1
2
3
4
lib/lib_dys.so: src/ThrDynStr.c src/ThrDynStr.h src/Vt-200.color.h
	@gcc …
lib/lib_symbo.so: src/Symbo.c src/Symbo.h src/Symbo_debug.c src/ThrDynStr.c src/ThrDynStr.h src/Vt-200.color.h
	@gcc …

En espérant aider d'autres newbies dans l'utilisation de make.

NOTE au modérateur(s) : si vous pensez que ce post peut être utile, peut-être serait-il bien de changer le titre du thread pour qu'il comporte le mot "make"