[G++] in-charge / not-in-charge erreur à l'edition des liens

Le
Emmanuel
Bonjour,

J'ai une erreur assez particulière à l'édition des liens d'un programme C++
sous Linux (avec g++). Il y a des références vers des constructeurs
in-charge / not-in-charge qui me laissent perplexe (je n'ai pas vraiment
compris ce qu'indiquaient ces messages). En effet, tout le passage de
compilation se passe sans problème, ce qui indique que tout est proprement
déclaré (pas de warning). J'ai de plus vérifié et les signatures des
implémentations correspondent bien aux interfaces des .h. Les
bibliothèques .a sont faites avec la commande "ar rcs".

J'ai remarqué que les erreurs ne portaient que sur des constructeurs et des
destructeurs, mais je ne sais pas si ce n'est qu'une coïncidence

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites

scenario/libscenario.a(Scenario.o)(.text+0x21c): In function
`Scenario::Scenario[not-in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x27f):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

scenario/libscenario.a(Scenario.o)(.text+0x554): In function
`Scenario::Scenario[in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x5b7):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

collect2: ld returned 1 exit status
make: *** [satellite] Erreur 1

Je ne sais plus trop quoi faire, sachant que le code me semble à priori bon,
et que je ne travaillais pas précisement sur ces points quand l'erreur est
arrivée. Le code et les makefiles sont disponible sur simple demande.

--
manu
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
kanze
Le #734265
Emmanuel news:
J'ai une erreur assez particulière à l'édition des liens d'un
programme C++ sous Linux (avec g++). Il y a des références vers des
constructeurs in-charge / not-in-charge qui me laissent perplexe (je
n'ai pas vraiment compris ce qu'indiquaient ces messages).


Si j'ai bien compris (je n'suis pas allé régarder les sources de g++),
g++ génère deux versions de chaque constructeur -- une pour quand il est
appelé comme le constructeur de la classe la plus dérivée, et une autre
pour le cas où il est appelé depuis le constructeur d'une classe
dérivée. (Je ne suis pas certain que c'est ça, mais ça me semble
probable. Aussi, je ne sais pas s'il génère les deux versions
systèmatiquement, ou seulement dans certains cas -- dès qu'il y a des
bases virtuelles, en tout cas, le comportement du constructeur ne doit
pas être pareil dans les deux cas.)

En effet, tout le passage de compilation se passe sans problème, ce
qui indique que tout est proprement déclaré (pas de warning).


Pourquoi pas ? Si c'est un problème d'une définition qui manque, il ne
doit pas y avoir de problème lors de la compilation.

J'ai de plus vérifié et les signatures des implémentations
correspondent bien aux interfaces des .h. Les bibliothèques .a sont
faites avec la commande "ar rcs".


Est-ce qu'il faut un coup de ranlib ? Je ne crois pas, mais dans le
temps, c'était nécessaire. Si le programme existe sur ta machine,
essaie-le. (En général, si le programme existe, il est nécessaire. Mais
il arrive souvent qu'on le « crée » avec un lien sur « true », de façon
à ce que les vieux fichiers de make continue à fonctionner.)

J'ai remarqué que les erreurs ne portaient que sur des constructeurs
et des destructeurs, mais je ne sais pas si ce n'est qu'une
coïncidence...

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites


J'ai comme une doute : en général, les éditeurs de liens Unix traite les
fichiers dans la ligne de commande dans l'ordre. Que le fichier soit
spécifié par son nom et son chemin complet, ou par une option -l. C-à-d
que des options -l avant les fichiers d'objet ne servent strictement à
rien ; tant qu'on n'a pas traité au moins un fichier objet, il n'y a pas
d'externe non résolu, donc, on n'incorpore rien du fichier bibliothèque.

Attention aussi à l'ordre des -l entre eux. Si par exemple dans ton cas,
un objet dans libglut.a ou libGLU.a utilise des symboles de libXmu.a ou
de libXi.a, il ne va pas les trouver.

scenario/libscenario.a(Scenario.o)(.text+0x21c): In function
`Scenario::Scenario[not-in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'


Le message est assez clair : il y a eu construction d'un objet de type
ScenarioParser dans l'objet Scenario.o, et le compilateur n'en a pas
trouver son constructeur. Ou bien, tu n'as pas spécifié la bibliothèque,
ou bien, tu l'as spécifier trop tôt, ou bien, l'objet avec le
constructeur est dans la même bibliothèque, mais il faut un coup de
ranlib, ou bien, quelqu'un a oublié de l'écrire carrément. Ou le
constructeur était prévu inline, mais on a oublié d'en fournir la
définition dans le Scenario.cpp.

Pour commencer, je mettrais les options de l'édition de lien dans
l'ordre habituel, c-à-d d'abord les objets, puis les bibliothèques et
les -l, avec les bibliothèques et les -l dans l'ordre, avec les clients
avant les fournisseurs. Puis, je verrais s'il y a un programme ranlib
sur la machine, et si oui, je m'en servirais sur les bibliothèques.

[Autres erreurs coupées -- c'était toujours de la même chose...]

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jan Rendek
Le #734264
Emmanuel wrote:
Bonjour,

J'ai une erreur assez particulière à l'édition des liens d'un programme C++
sous Linux (avec g++). Il y a des références vers des constructeurs
in-charge / not-in-charge qui me laissent perplexe (je n'ai pas vraiment
compris ce qu'indiquaient ces messages). En effet, tout le passage de
compilation se passe sans problème, ce qui indique que tout est proprement
déclaré (pas de warning). J'ai de plus vérifié et les signatures des
implémentations correspondent bien aux interfaces des .h. Les
bibliothèques .a sont faites avec la commande "ar rcs".

J'ai remarqué que les erreurs ne portaient que sur des constructeurs et des
destructeurs, mais je ne sais pas si ce n'est qu'une coïncidence...

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites

scenario/libscenario.a(Scenario.o)(.text+0x21c): In function
`Scenario::Scenario[not-in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x27f):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

scenario/libscenario.a(Scenario.o)(.text+0x554): In function
`Scenario::Scenario[in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x5b7):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

collect2: ld returned 1 exit status
make: *** [satellite] Erreur 1

Je ne sais plus trop quoi faire, sachant que le code me semble à priori bon,
et que je ne travaillais pas précisement sur ces points quand l'erreur est
arrivée. Le code et les makefiles sont disponible sur simple demande.


Certaines fonctions on l'air définies mais pas déclarées.

Est-tu sûr d'avoir fourni une implementation des fonctions suivantes:
ScenarioParser::~ScenarioParser()
ScenarioParser::ScenarioParser(char*,GlobalParameters*, Scenario*)

A mon avis, soit la définition de ces fonctions est manquante, soit
le fichier objet correspondant à la classe ScenarioParser n'a pas
été inclus dans les bibliothèques et objets passés au linker.

Il est tout à fait normale que ce genre d'erreur se déclare maintenant
si tu n'as jamais instancié d'objet de type ScenarioParser auparavant.

--
Jan Rendek
INRIA Lorraine
r e n d e k @ l o r i a . f r

Gabriel Dos Reis
Le #734010
Emmanuel
| Bonjour,
|
| J'ai une erreur assez particulière à l'édition des liens d'un programme C++
| sous Linux (avec g++).

Concrêtement, cela veut dire que tu as oublié de définir des
contructeurs que tu as déclarés et utilisés dans ton programe
(probablement ainsi que d'autres fonctions virtuelles).

-- Gaby
bastien.armand
Le #731585
Emmanuel
Bonjour,

J'ai une erreur assez particulière à l'édition des liens d'un programme C++
sous Linux (avec g++). Il y a des références vers des constructeurs
in-charge / not-in-charge qui me laissent perplexe (je n'ai pas vraiment
compris ce qu'indiquaient ces messages). En effet, tout le passage de
compilation se passe sans problème, ce qui indique que tout est proprement
déclaré (pas de warning). J'ai de plus vérifié et les signatures des
implémentations correspondent bien aux interfaces des .h. Les
bibliothèques .a sont faites avec la commande "ar rcs".

J'ai remarqué que les erreurs ne portaient que sur des constructeurs et des
destructeurs, mais je ne sais pas si ce n'est qu'une coïncidence...

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites

scenario/libscenario.a(Scenario.o)(.text+0x21c): In function
`Scenario::Scenario[not-in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x27f):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

scenario/libscenario.a(Scenario.o)(.text+0x554): In function
`Scenario::Scenario[in-charge](char*, GlobalParameters*)':
/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:17:
undefined reference to `ScenarioParser::ScenarioParser[in-charge](char*,
GlobalParameters*, Scenario*)'

scenario/libscenario.a(Scenario.o
(.text+0x5b7):/export/home/users/ILOG/ILOG-2003/coiriere/satellitesCVS/satellites/src/scenario/Scenario.cpp:19:
undefined reference to `ScenarioParser::~ScenarioParser [in-charge]()'

collect2: ld returned 1 exit status
make: *** [satellite] Erreur 1

Je ne sais plus trop quoi faire, sachant que le code me semble à priori bon,
et que je ne travaillais pas précisement sur ces points quand l'erreur est
arrivée. Le code et les makefiles sont disponible sur simple demande.


Bonjour,

Je vais essayer de te repondre ;)

Tu n'as pas de probleme de code mais un probleme de link (comment ca
se dit en francais ?) Il t'indique qu'il ne trouve pas certaines
fonctions dans la liste des objets et des bibliotheques que tu as
indiquees sur la ligne de commande.

Tu as probablement oublie de lui indique un fichier objet (.o) ou une
archive (.a) (ou alors tu as oublie d'inclure un .o dans ton archive),
a priori ScenarioParser.o. Tu peux aussi utiliser la commande nm pour
voir les symboles definis (exemple : nm libScenario.a | grep
ScenarioParser pour voir si les methodes de ScenarioParser sont bien
incluses dans ton archive).

Il me semble que le in-charge n'as pas beaucoup de sens (interne a
gcc).

Voila, j'espere ne pas etre trop a cote de la plaque...

Emmanuel
Le #731583
Bastien wrote:

Emmanuel news:
Bonjour,

J'ai une erreur assez particulière à l'édition des liens d'un programme
...


l'erreur est arrivée. Le code et les makefiles sont disponible sur simple
demande.


Bonjour,

Je vais essayer de te repondre ;)

Tu n'as pas de probleme de code mais un probleme de link (comment ca
se dit en francais ?) Il t'indique qu'il ne trouve pas certaines


édition des liens (il me semble)

fonctions dans la liste des objets et des bibliotheques que tu as
indiquees sur la ligne de commande.

Tu as probablement oublie de lui indique un fichier objet (.o) ou une
archive (.a) (ou alors tu as oublie d'inclure un .o dans ton archive),
a priori ScenarioParser.o. Tu peux aussi utiliser la commande nm pour
voir les symboles definis (exemple : nm libScenario.a | grep
ScenarioParser pour voir si les methodes de ScenarioParser sont bien
incluses dans ton archive).


Alors, après multiples vérifications, l'ensembles des objets, symboles et
déclarations se trouvaient bien dans les bons fichiers / archives.
(vérification scrupuleuse avec nm). Par contre, il faut absolument faire
attention à l'ordre des objets passés en paramètres... (Voir mes autres
réponses)

Voila, j'espere ne pas etre trop a cote de la plaque...


Merci pour le nm, c'était une commande que je cherchais...

--
manu


Emmanuel
Le #731582
wrote:

Emmanuel news:
J'ai une erreur assez particulière à l'édition des liens d'un
programme C++ sous Linux (avec g++). Il y a des références vers des
constructeurs in-charge / not-in-charge qui me laissent perplexe (je
n'ai pas vraiment compris ce qu'indiquaient ces messages).


Si j'ai bien compris (je n'suis pas allé régarder les sources de g++),
g++ génère deux versions de chaque constructeur -- une pour quand il est
appelé comme le constructeur de la classe la plus dérivée, et une autre
pour le cas où il est appelé depuis le constructeur d'une classe
dérivée. (Je ne suis pas certain que c'est ça, mais ça me semble
probable. Aussi, je ne sais pas s'il génère les deux versions
systèmatiquement, ou seulement dans certains cas -- dès qu'il y a des
bases virtuelles, en tout cas, le comportement du constructeur ne doit
pas être pareil dans les deux cas.)


d'après les résultats de la commande nm, il générerait deux constructeurs
(et deux destructeurs) à chaque fois. C'est peut-être ça la différence
entre "in charge" et "not in charge", non ?

J'ai de plus vérifié et les signatures des implémentations
correspondent bien aux interfaces des .h. Les bibliothèques .a sont
faites avec la commande "ar rcs".


Est-ce qu'il faut un coup de ranlib ? Je ne crois pas, mais dans le
temps, c'était nécessaire. Si le programme existe sur ta machine,
essaie-le. (En général, si le programme existe, il est nécessaire. Mais
il arrive souvent qu'on le « crée » avec un lien sur « true », de façon
à ce que les vieux fichiers de make continue à fonctionner.)


il y a bien un "vrai" ranlib, mais l'erreur ne viens pas de là, puisque
celle-ci est corrigée sans appel à ranlib.

J'ai remarqué que les erreurs ne portaient que sur des constructeurs
et des destructeurs, mais je ne sais pas si ce n'est qu'une
coïncidence...

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites


J'ai comme une doute : en général, les éditeurs de liens Unix traite les
fichiers dans la ligne de commande dans l'ordre. Que le fichier soit
...

Pour commencer, je mettrais les options de l'édition de lien dans
l'ordre habituel, c-à-d d'abord les objets, puis les bibliothèques et
les -l, avec les bibliothèques et les -l dans l'ordre, avec les clients
avant les fournisseurs. Puis, je verrais s'il y a un programme ranlib
sur la machine, et si oui, je m'en servirais sur les bibliothèques.


Il s'agissait bien d'une erreur d'ordre des archives. Mais l'erreur n'a pas
été si facile que ça a dénicher car quelque soit l'ordre, une erreur de
dépendance se produisait. Il y a des dépendances croisées qui ne peuvent
être résolues que par la lecture multiple de la même bibliothèque.

La ligne de compilation finale est donc
g++ GlobalParameters.o SatellitesViewer.o -Xlinker -( graphic/libgraphic.a
scenario/libscenario.a scenario/events/libevents.a inputoutput/libin
putoutput.a -Xlinker -) -lxerces-c -lXi -lXmu -lGLU -lglut -o satellites

l'option -Xlinker permettant simplement de passer les options -( et -) à ld.
Ces deux options permettent à ld de relire plusieurs fois les fichiers qui
sont entre ces deux paramètres, afin de résoudre des références croisées.
C'est une solution de facilité, mais elle marche.

--
James Kanze GABI Software mailto:


Merci pour tout !

--
manu


kanze
Le #724105
Emmanuel news:
wrote:

Emmanuel news:
J'ai une erreur assez particulière à l'édition des liens d'un
programme C++ sous Linux (avec g++). Il y a des références vers des
constructeurs in-charge / not-in-charge qui me laissent perplexe
(je n'ai pas vraiment compris ce qu'indiquaient ces messages).


Si j'ai bien compris (je n'suis pas allé régarder les sources de
g++), g++ génère deux versions de chaque constructeur -- une pour
quand il est appelé comme le constructeur de la classe la plus
dérivée, et une autre pour le cas où il est appelé depuis le
constructeur d'une classe dérivée. (Je ne suis pas certain que c'est
ça, mais ça me semble probable. Aussi, je ne sais pas s'il génère
les deux versions systèmatiquement, ou seulement dans certains cas
-- dès qu'il y a des bases virtuelles, en tout cas, le comportement
du constructeur ne doit pas être pareil dans les deux cas.)


d'après les résultats de la commande nm, il générerait deux
constructeurs (et deux destructeurs) à chaque fois. C'est peut-être ça
la différence entre "in charge" et "not in charge", non ?


J'avais déjà constaté chez moi qu'au moins dans certains cas, g++ génère
deux constructeurs (ou plutôt deux points d'entrée) pour chaque
constructeur que j'écris, qu'il appelle « in charge » et « not in charge ».
Je ne sais pas si c'est systèmatique, ni exactement quel est la
différence ; j'ai spéculé qu'il avait à faire à s'il fallait appeler les
constructeurs des bases virtuelles ou non, mais j'avoue que ce n'est que
de la spéculation de ma part.

J'ai de plus vérifié et les signatures des implémentations
correspondent bien aux interfaces des .h. Les bibliothèques .a sont
faites avec la commande "ar rcs".


Est-ce qu'il faut un coup de ranlib ? Je ne crois pas, mais dans le
temps, c'était nécessaire. Si le programme existe sur ta machine,
essaie-le. (En général, si le programme existe, il est nécessaire.
Mais il arrive souvent qu'on le « crée » avec un lien sur « true »,
de façon à ce que les vieux fichiers de make continue à
fonctionner.)


il y a bien un "vrai" ranlib, mais l'erreur ne viens pas de là,
puisque celle-ci est corrigée sans appel à ranlib.


Si tu repasses suffisamment de fois sur la même bibliothèque, il n'y a
jamais besoin de ranlib. S'il existe, sers-t'en. Il ne peut pas faire du
mal. (J'ai un ranlib chez moi, sous Solaris, mais c'est un script de
shell qui ne fait que « exit 0 ». Selon les commentaires dans le
script : « This script is provided as a convenience for software
developers who need to maintain Makefiles that are portable across a
variety of operating systems. »)

J'ai remarqué que les erreurs ne portaient que sur des
constructeurs et des destructeurs, mais je ne sais pas si ce n'est
qu'une coïncidence...

G++ (ou plutot ld) m'affiche le resultat suivant à l'édition des liens :

$ g++ -g3 -Wall -lxerces-c -lXi -lXmu -lGLU -lglut GlobalParameters.o
SatellitesViewer.o scenario/events/libevents.a graphic/libgraphic.a
inputoutput/libinputoutput.a scenario/libscenario.a -o satellites


J'ai comme une doute : en général, les éditeurs de liens Unix traite
les fichiers dans la ligne de commande dans l'ordre. Que le fichier
soit
...

Pour commencer, je mettrais les options de l'édition de lien dans
l'ordre habituel, c-à-d d'abord les objets, puis les bibliothèques
et les -l, avec les bibliothèques et les -l dans l'ordre, avec les
clients avant les fournisseurs. Puis, je verrais s'il y a un
programme ranlib sur la machine, et si oui, je m'en servirais sur
les bibliothèques.


Il s'agissait bien d'une erreur d'ordre des archives. Mais l'erreur
n'a pas été si facile que ça a dénicher car quelque soit l'ordre, une
erreur de dépendance se produisait. Il y a des dépendances croisées
qui ne peuvent être résolues que par la lecture multiple de la même
bibliothèque.


C'est un problème classique. AMHA, une cycle dans la graphe des
dépendences relève toujours d'une erreur de conception. Mais elles
arrivent, et on n'est pas toujours maître de tout, pour pouvoir les
éliminer. Alors, s'il faut traiter une bibliothèque de multiples fois,
il faut le faire.

La ligne de compilation finale est donc
g++ GlobalParameters.o SatellitesViewer.o -Xlinker -( graphic/libgraphic.a
scenario/libscenario.a scenario/events/libevents.a inputoutput/libin
putoutput.a -Xlinker -) -lxerces-c -lXi -lXmu -lGLU -lglut -o satellites

l'option -Xlinker permettant simplement de passer les options -( et -)
à ld. Ces deux options permettent à ld de relire plusieurs fois les
fichiers qui sont entre ces deux paramètres, afin de résoudre des
références croisées. C'est une solution de facilité, mais elle marche.


Attention : elle n'est pas portable. Cette option n'est pas présente
dans le ld de Solaris, par exemple. Si c'était moi, 1) je me servirais
bien de ranlib, et 2) je chercherais d'où vient la cycle -- si c'est
dans les bibliothèques dont j'ai le contrôl, je chercherais s'il n'y
avait pas de moyen raisonnable à l'éliminer, peut-être simplement en
fusionnant deux bibliothèques, ou en déplaçant un objet d'une
bibliothèque à l'autre. Sinon, je repetterai les bibliothèques qu'il
faut dans la ligne de commande. Évidemment, éliminer la cycle, c'est ce
qu'il y a de mieux, mais c'est parfois plus facile à dire qu'à faire.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Jean-Marc Bourguet
Le #724103
writes:

Attention : elle n'est pas portable. Cette option n'est pas présente
dans le ld de Solaris, par exemple. Si c'était moi, 1) je me servirais
bien de ranlib, et 2) je chercherais d'où vient la cycle -- si c'est
dans les bibliothèques dont j'ai le contrôl, je chercherais s'il n'y
avait pas de moyen raisonnable à l'éliminer, peut-être simplement en
fusionnant deux bibliothèques, ou en déplaçant un objet d'une
bibliothèque à l'autre.


Bizarre, tu ne cites pas la technique la plus courante d'apres mon
experience: creer une troisieme bibliothèque. Les cycles provenant
souvent de ce qu'on fournit des fonctionnalites de niveau
d'abstraction plus eleve. Au depart tout va bien puis on a besoin de
quelque chose de deja disponible d'un niveau intermediaire et on
introduit le cycle.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

kanze
Le #723816
Jean-Marc Bourguet news:
writes:

Attention : elle n'est pas portable. Cette option n'est pas présente
dans le ld de Solaris, par exemple. Si c'était moi, 1) je me servirais
bien de ranlib, et 2) je chercherais d'où vient la cycle -- si c'est
dans les bibliothèques dont j'ai le contrôl, je chercherais s'il n'y
avait pas de moyen raisonnable à l'éliminer, peut-être simplement en
fusionnant deux bibliothèques, ou en déplaçant un objet d'une
bibliothèque à l'autre.


Bizarre, tu ne cites pas la technique la plus courante d'apres mon
experience: creer une troisieme bibliothèque. Les cycles provenant
souvent de ce qu'on fournit des fonctionnalites de niveau
d'abstraction plus eleve. Au depart tout va bien puis on a besoin de
quelque chose de deja disponible d'un niveau intermediaire et on
introduit le cycle.


On effet, j'ai oublié cet alternatif. En fait, si tu as trois niveaux
d'abstraction, 1, 2, 3, tu peux les mettre tous dans des bibliothèques
différentes ou tous dans la même bibliothèque, mais tu ne peux pas
mettre 1 et 3 dans une bibliothèque, et 2 dans une autre, sans risque de
cycles.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Emmanuel
Le #725915

C'est un problème classique. AMHA, une cycle dans la graphe des
dépendences relève toujours d'une erreur de conception. Mais elles
arrivent, et on n'est pas toujours maître de tout, pour pouvoir les
éliminer. Alors, s'il faut traiter une bibliothèque de multiples fois,
il faut le faire.


le problème a été corrigé par le déplacement d'une classe qui, en effet,
n'avais rien à faire là où elle était... et ça marche mieux.

Attention : elle n'est pas portable. Cette option n'est pas présente
dans le ld de Solaris, par exemple. Si c'était moi, 1) je me servirais


je note, ça sera utile...

--
manu

Publicité
Poster une réponse
Anonyme