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*)'
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*)'
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*)'
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,
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,
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,
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,
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,
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.
Emmanuel wrote in message
news:<4096a1fa$0$317$...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
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).
Voila, j'espere ne pas etre trop a cote de la plaque...
Emmanuel <manuco@club-internet.fr> wrote in message
news:<4096a1fa$0$317$7a628cd7@news.club-internet.fr>...
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
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).
Voila, j'espere ne pas etre trop a cote de la plaque...
Emmanuel wrote in message
news:<4096a1fa$0$317$...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
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).
Voila, j'espere ne pas etre trop a cote de la plaque...
Emmanuel wrote in message
news:<4096a1fa$0$317$...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.)
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
...
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.
--
James Kanze GABI Software mailto:
Emmanuel <manuco@club-internet.fr> wrote in message
news:<4096a1fa$0$317$7a628cd7@news.club-internet.fr>...
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.)
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
...
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.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Emmanuel wrote in message
news:<4096a1fa$0$317$...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.)
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
...
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.
--
James Kanze GABI Software mailto:
wrote:Emmanuel wrote in message
news:<4096a1fa$0$317$...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.
kanze@gabi-soft.fr wrote:
Emmanuel <manuco@club-internet.fr> wrote in message
news:<4096a1fa$0$317$7a628cd7@news.club-internet.fr>...
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.
wrote:Emmanuel wrote in message
news:<4096a1fa$0$317$...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.
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.
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.
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.
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.
kanze@gabi-soft.fr 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.
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.
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.
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
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.
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
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.
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