Compilation/édition de liens

Bonjour,

La chose parait correcte, à vérifier simplement si la librairie que tu as est bien nommée sous la forme libMatrix.a.

Mais, le point sur lequel je suis pessimiste est Cygwin. Je ne l'ai jamais utilisé mais de mémoire il s'agit d'un environnement capable de simuler un noyaux linux sous Windows, à condition d'avoir recompilé chaque programme pour Cygwin. Il faudrait alors se procurer les sources de la librairie et la recompiler pour Cygwin pour que la librairie soit compatible. Je te laisse le soin d'explorer cette piste.

M.

Bonjour,

j'ai téléchargé les sources sur le site du CERN et je les ai compilé ensuite avec Cygwin.
Je ne sais pas si tu connais cette librairie, mais ROOT fonctionne un peu comme Matlab.
Tu peux l'utiliser de 2 manières en lancant ROOT à partir d'un prompt et taper des commandes.
Je pense que les binaires fonctionnent correctement car j'arrive à lancer ROOT et les fonctions que je veux utiliser, fonctionnent quand je les tape dans la fenêtre de commande.
Pour ma part je voudrai utiliser ROOT, en créant mes propres programmes C++ et en utilisant les classes de ROOT.

Depuis le dernier message, j'ai essayé :

gcc -o testb testb.o -L"D:/root/bin" -lCint -lCore -lMatrix

car il existe des dépendances entre les librairies, cette fois les librairies sont bien trouvées mais j'ai des messages de type :

undefined reference to 'std::basic_string<char>'
undefined reference to 'std::char_traits<char>'
undefined reference to 'std::ios_base::Init::Init<>'
undefined reference to '___cxa_pure_virtual'

Les librairies en question sont du type dll :

libCore.dll
libCint.dll
libMatrix.dll

faut il rajouter une option à la ligne d'édition de liens ?

C'est encore d'autres librairies qui manquent, les premières sont donc okay.

Pour les trois premières références, elles proviennent du runtime C. (et même C++)

Je ne sais pas comment il s'appelle avec Cygwin, sous Windows on a les msvcrt.lib, sous Linux la libc.so.

Les noms courants sont "Runtime Environment", (d'où parfois le crt) ou la "libc". Il doit y avoir ça dans un coin de Cygwin car ce coup-ci ce n'est pas générable à partir de fichiers sources.


D'une courte recherche il ressort un nom : libstdc++.a, à explorer...

M.

Bonjour,

la piste semble être la bonne, merci.
J'arrive à créer un exécutable, j'obtiens quand même un message :

Info: resolving _kAssertMsg by linking to __imp__kAssertMsg <auto-import>

Sais tu de quoi il s'agit ?

Bonjour,

C'est encore notre ami le linker. Il y a encore quelque chose qui a été déclaré mais il ne trouve pas le code correspondant, par contre (et je ne sais pas pourquoi il se permet ce genre de chose) il a trouvé un autre truc et il l'a mis à la place.

Soit ça passe, soit ton programme plantera dès qu'il ira chercher _kAssertMsg.

Il y a trois solution si ça plante.
- Prier.
- Trouver où l'élément manquant est rangé pour lui rajouter la librairie.
- Lui rajouter nous même cet élément.
et trois si ça ne plante pas:
- s'en contenter
- Trouver où l'élément manquant est rangé pour lui rajouter la librairie.
- Désactiver le message du linker (par contre il ne nous a pas donné son identifiant...)

En cas de plantage si la deuxième échoue je ferais la troisième... (bien documenté et dans un fichier à part du reste du code) car même si tu n'utilises pas cet élément peut-être que ROOT le fait en interne...

dans TError.h (vu ici sur le net)
Tout au bas il y a la déclaration de kAssertMsg qui est une chaîne de caractère.
Le mieux serait de faire un mini programme soit qui affiche cette chaîne et être fixé tout de suite, soit qui utilise les Assert définis en dessous.

Assert est une fonction de débuggage qui consiste à faire planter volontairement son programme si une condition n'est pas vérifiée et de d'afficher un message contenant l'expression fausse, le fichier et la ligne. Généralment on fait une fonction, on précise que le pointeur en paramètre doit être valide et plutôt que de tester chaque fois si le type a lu le commentaire on met un assert qui fera planter si le pointeur est nul: l'intérêt est que normalement le Assert n'est compilé que en mode debug.

Si il y a un blême tu peux juste ajouter un fichier .c avec la définition et voir si le linker est content avec ou non.

const char *kAssertMsg = "Assertion failled ";

C'est pas très beau mais il y a de forte chance que ce soit un problème de version de ROOT ou une chose du genre car il trouve très bien le message du kCheckMsg.

Tu peux toujours tenter de te mettre à la racine de ROOT en mode console et de lancer une recherche du style:
grep -r kCheckMsg *
et voir si il trouve un .c, .o ou .a où il y a ça.

M.

Alors ? on code même le dimanche ? ;-)

Bonjour,

oui même le dimanche ! Merci en tout cas de toutes ces précisions, l'informatique peut s'avérer compliqué quand on s'y connait pas trop.
Je suis moi plus spécialisé en mathématiques mais j'ai besoin d'un ordinateur pour travailler, en tout cas si j'ai d'autres pbs je te le ferai
savoir, si par hasard tu as des pbs en maths ce qui est plus rare dis le moi j'essaierai de t'aider.
@ +.

Bonjour,

désolé de revenir à la charge avec mon problème mais l'exécutable ne donne rien.
Comme tu l'as précisé, Assert doit sûrement faire planter le programme.
J'ai essayé plusieurs de tes solutions, mais soit je m'y suis mal pris soit ca ne marche pas.
Sûrement la première option.
J'ai essayé le " grep -r kCheckMsg * " , rien ne se passe, le shell ne rend pas la main.
Tu m'as également suggéré de faire un petit programme, qui affiche :

" const char *kAssertMsg = "Assertion failled "; "

peux tu être un peu plus précis et notemment lorsque tu parles de "trouver où l'élément manquant est rangé pour lui rajouter la librairie" ?

Merci d'avance.

Bonjour,

Le problème majeur est en fait le warning du linker. Il fait rarement de bêtise, en même temps, il râle rarement pour rien...

Pour ce qui est de la validité du programme, si tu as la possibilité de tester avec un tout petit programme qui ne fait que afficher kAssertMsg, on sera fixé sur le fait que le problème vient de là ou non. Un simple printf( "%s", kAssertMsg ); dans le main.

Ca c'est un premier point et c'est finalement le résultat le plus important.

Si ca plante alors on essaiera
1)
De trouver dans quelle librairie est cette variable (à part les docs ce n'est pas évident... on verra plus tard pour le grep)
2)
De télécharger une autre version de ROOT.
3)
De lui rajouter la partie manquante (à la barbare) via le
const char *kAssertMsg = "Une phrase de remplacement ";

M.

Bonjour,

j'ai essayé le printf( "%s", kAssertMsg ); dans le main sans succès, le programme me renvoie la main.
Idem quand je rajoute :

const char *kAssertMsg = "Une phrase de remplacement ";

A l'exception que je n'ai plus le message :

Info: resolving _kAssertMsg by linking to __imp__kAssertMsg <auto-import>

la définition de kAssertMsg apparaît dans le fichier root/base/inc/Terror.h ainsi que dans Terror.cxx du même répertoire mais je ne sais pas à quelle librairie cela correspond.

Salut.
Moi le message du linker ne me posserai pas plus de problème que ça, je l'ai souvent eu lors d'édition de liens avec des dll.
En plus, c'est n'est ni un warning ni une erreur, il marque "info:" Je pense que le problème viens d'ailleurs.
utilise le debuggeur et fait des sorties écran pour voir d'où le problème peux venir.