Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: XCode C99 : duplicate symbol

3 views
Skip to first unread message

Olivier Miakinen

unread,
Apr 22, 2022, 6:30:17 AM4/22/22
to
Bonjour,

Le 19/04/2022 à 10:26, kurtz le pirate a écrit :
> Bonjour,
>
> Si de vieux dinosaures passent par la...

Plutôt que de chercher des dinosaures sur un groupe Mac, pourquoi
ne pas poser la question sur le groupe où c'est en charte ? Je fais
suivre.

>
> Dans mon projet, j'ai ces fichiers :
> a_structures.h
> a_toolbox.h
> a_toolbox.c
> a_m.h
> a_m.c
> main.c
>
> Le fichier a_structures.h ne contient que des définitions de structures.
>
> Dans main.c j'ai :
> #include "a_structures.h"
> #include "a_toolbox.h"
> #include "a_m.h"
>
>
> J'ai un tableau de chaines :
> const char * DaysNames[] = {
> "Dimanche","Lundi","Mardi","Mercredi","Jeudi","Vendredi","Samedi" };
>
> que j'utilise dans le main.c :
> printf(" Le 30/6/1954 est un %s (%d)\n", DaysNames[dayofweek], dayofweek);
>
>
>
> Si le tableau est déclaré dans le main.c pas de problème.

Tel que tu l'as écrit, il n'est pas seulement déclaré mais défini.

>
> Si le tableau est déclaré dans le a_structures.h, le compilateur sort
> une erreur :
> duplicate symbol _DaysNames in:
> /Users/.../main.o
> /Users/.../a_m.o
> /Users/.../a_toolbox.o
>
> Et la je ne comprends plus...
> Si vous avez une idée. Merci d'avance.

Parce qu'en le mettant dans un .h inclus dans différents .c, tu le
redéfinis dans chacun des .c .

Plusieurs solutions possibles : soit tu le définis en 'static', auquel
cas chaque .c aura sa propre copie du tableau, soit tu le déclares
uniquement dans le .h et tu le définis dans un seul .c .



--
Olivier Miakinen

kurtz le pirate

unread,
Apr 22, 2022, 2:13:18 PM4/22/22
to
On 22/04/2022 12:30, Olivier Miakinen wrote:
> Bonjour,
>
> Le 19/04/2022 à 10:26, kurtz le pirate a écrit :
>> Bonjour,
>>
>> Si de vieux dinosaures passent par la...
>
> Plutôt que de chercher des dinosaures sur un groupe Mac, pourquoi
> ne pas poser la question sur le groupe où c'est en charte ? Je fais
> suivre.

parceque XCode = Mac ;)


>> Dans mon projet, j'ai ces fichiers :
>> a_structures.h
>> a_toolbox.h
>> a_toolbox.c
>> a_m.h
>> a_m.c
>> main.c
>>
>> Le fichier a_structures.h ne contient que des définitions de structures.
>>
>> Dans main.c j'ai :
>> #include "a_structures.h"
>> #include "a_toolbox.h"
>> #include "a_m.h"
>>
>>
>> J'ai un tableau de chaines :
>> const char * DaysNames[] = {
>> "Dimanche","Lundi","Mardi","Mercredi","Jeudi","Vendredi","Samedi" };
>>
>> que j'utilise dans le main.c :
>> printf(" Le 30/6/1954 est un %s (%d)\n", DaysNames[dayofweek], dayofweek);
>>
>>
>>
>> Si le tableau est déclaré dans le main.c pas de problème.
>
> Tel que tu l'as écrit, il n'est pas seulement déclaré mais défini.

oui, déclaré ET défini. j'ai écris trop vite.

>>
>> Si le tableau est déclaré dans le a_structures.h, le compilateur sort
>> une erreur :
>> duplicate symbol _DaysNames in:
>> /Users/.../main.o
>> /Users/.../a_m.o
>> /Users/.../a_toolbox.o
>>
>> Et la je ne comprends plus...
>> Si vous avez une idée. Merci d'avance.
>
> Parce qu'en le mettant dans un .h inclus dans différents .c, tu le
> redéfinis dans chacun des .c .

oui... mais non. dans mes .c, je n'ai pas de #include "a_structures.h"
les #include ne sont que dans les .h


> Plusieurs solutions possibles : soit tu le définis en 'static', auquel
> cas chaque .c aura sa propre copie du tableau, soit tu le déclares
> uniquement dans le .h et tu le définis dans un seul .c .

je vais regarder du coté de 'static'.
j'ai vu aussi un pragma 'once'.

merci pour la piste.


--
kurtz le pirate
compagnie de la banquise





--
kurtz le pirate
compagnie de la banquise

Olivier Miakinen

unread,
Apr 23, 2022, 11:20:59 AM4/23/22
to
Le 22/04/2022 20:13, kurtz le pirate a écrit :
>>>
>>> Si de vieux dinosaures passent par la...
>>
>> Plutôt que de chercher des dinosaures sur un groupe Mac, pourquoi
>> ne pas poser la question sur le groupe où c'est en charte ? Je fais
>> suivre.
>
> parceque XCode = Mac ;)

Désolé, je ne connaissais pas.

Quoi qu'il en soit, ça ressemble beaucoup à du langage C, et à moins qu'il
y ait une spécificité Mac j'ai l'impression que les compétences en C
devraient pouvoir t'aider.

>>> Dans mon projet, j'ai ces fichiers :
>>> a_structures.h
>>> a_toolbox.h
>>> a_toolbox.c
>>> a_m.h
>>> a_m.c
>>> main.c
>>>
>>> Le fichier a_structures.h ne contient que des définitions de structures.

Ok.

>>>
>>> Dans main.c j'ai :
>>> #include "a_structures.h"
>>> #include "a_toolbox.h"
>>> #include "a_m.h"

[...]

>>
>> Parce qu'en le mettant dans un .h inclus dans différents .c, tu le
>> redéfinis dans chacun des .c .
>
> oui... mais non. dans mes .c, je n'ai pas de #include "a_structures.h"

Tu l'as au moins dans le main.c, d'après ce que tu écrivais plus haut.

> les #include ne sont que dans les .h

Eh bien si tu n'inclus pas directement a_structures.h dans a_m.c et
a_toolbox.c, c'est forcément qu'il est inclus de façon indirecte,
que ce soit par un autre #include, soit parce que XCode fait ça de
manière implicite.

Pour t'en convaincre, écris dans a_structures.h quelque chose provoquant
une erreur de compilation plutôt qu'une erreur détectée à l'édition de
liens, par exemple :

#error Le fichier .h est inclus dans ce .c !

>> Plusieurs solutions possibles : soit tu le définis en 'static', auquel
>> cas chaque .c aura sa propre copie du tableau, soit tu le déclares
>> uniquement dans le .h et tu le définis dans un seul .c .
>
> je vais regarder du coté de 'static'.


Le plus propre à mon avis serait de ne mettre que la déclaration dans le .h :

extern const char * DayNames[];

et la définition dans l'un des .c, par exemple main.c


Sinon, oui, une définition statique est possible puisque ça ne prend que
quelques octets dans chacun des .c, et que le tableau n'a pas besoin d'être
partagé puisqu'il ne devrait pas être modifié.


> j'ai vu aussi un pragma 'once'.

Ça, outre que ce n'est pas standard (quoique assez largement supporté), il
me semble que ça peut éviter d'inclure plusieurs fois la même définition
dans un même .c, mais que ça n'empêchera pas que cette définition soit
incluse une fois dans chaque .c : ça ne devrait donc strictement rien
changer à ton problème.


--
Olivier Miakinen

0 new messages