Version imprimable
Salut,
J'ai essayé de lancer le processus de compilation des versions debug des dll pour Qt 4.4.0 final.
Lors de l'édition de liens de QtXml, l'éditeur de liens se plaint de définitions multiples pour QChar.
Quelqu'un s'étant déjà frotté au problème y a-t-il trouvé une solution :question:
Salut,
Quel est le message exact stp? (si tu as des doutes, poste la trace complète).
Et aussi, quel compilo/système?
Ainsi que je l'ai écrit, l'éditeur de liens m'éjecte en se plaignant d'une déclaration multiple de QChar.
Cela prend la forme du message:
et continue avec la plupart des constructeurs de QChar...Citation:
windres -i QtXmld_ressource.rc -o tmp\obj\debug_shared\QtXmld_ressource_res.o --include_dir=.
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -wl,-enable-runtime-pseudo-reloc -mthreads -Wl -shared -Wl,--out-implib,c:\Qt\4.4.0\libQtXmld4.a - ..\..\lib\QtXmld4.dll tmp/obj/debug_shared/qdom.o tmp/obj/debug_shared/qxml.o tmp/obj/debug_shared/qxmlstream.o -L"c:\Qt\4.4.0\lib" -L"c:\Qt\4.4.0\lib" tmp\obj\debug_shared\QtXmld_ressource_res.o -lQtCored4
Création du fichier de bibliothèque libQtXmld4.a
libQtXmld4.a(d001493.o): (.text +0x0) : définition multiples de QChar::QChar(int)
chemin-vers/qchar.h: 374: QChar défini pour la première fois ici
libQtXmld4.a(d001488.o): (.text +0x0) : définition multiples de QChar::QChar(QLatin1Char)
chemin-vers/qchar.h: 376: QChar défini pour la première fois ici
Bref, je ne serais pas surpris outre mesure que le problème vienne, d'une manière ou d'une autre, de la liaison avec QtCored4... mais la bonne question est donc de savoir comment y remédier :aie:
Pour info, j'essaye de compiler les bibliothèque en version debug, sous windows XP pro, avec Gcc 4.3.0
Gcc 4.3 ????
elle est sortie sous windows?
Tu sembles oublier à qui tu t'adresse :DCitation:
Envoyé par Mongaulois
Elle fonctionne très bien, avec une compilation "a mano" :D 8O
Je suis un peu scié là; mais bon gcc 4.3 c'est la version Testing, donc voilà :D
Tu ne peux pas revenir sur la dernière version stable? (voire le mingw que tu peux downloader direct par l'installeur de Qt-mingw)
Pourquoi, parce que j'ai compilé Gcc 4.3.0 sous windows :question:Citation:
Envoyé par IrmatDen
Ah, non, elle est en release...cf l'annonceCitation:
mais bon gcc 4.3 c'est la version Testing, donc voilà :D
Ce qui se passe, c'est qu'elle implémente déjà ce qui est sorti des drafts de la norme c++0x, ce qui fait qu'elle est susceptible d'évoluer...
pour quoi faire :question: l'installateur voudrait de toutes manières installer une version très ancienne de l'api windows...Citation:
Tu ne peux pas revenir sur la dernière version stable? (voire le mingw que tu peux downloader direct par l'installeur de Qt-mingw)
Et, comme c'est à l'édition des liens que make m'éjecte...
Non, j'ai posté ma réponse sans avoir la tienne en fait. Je suis scié par l'erreur parce qu'elle est purement "débile".Citation:
Envoyé par koala01
Ahem. sf.net n'est pas d'accord pour la version windows. Puisque tu l'as compilé toi même, j'aurais tendance à parier que l'erreur vient du compilo, pas de Qt.Citation:
Envoyé par koala01
PS: d'avance, non je ne sais pas à qui je parle, mais une tambouille faite main, c'est source de problème.
Ce n'est pas parce que MinGW décide de ne mettre Gcc 4.3.0 qu'en version testing que le compilateur n'est pas en version stable :D
La version 4.3.0 est bel et bien considérée comme stable par le site de Gcc, et j'ai compilé l'ensemble des pré-requis au départ de leurs sources dans la version stable :D
En outre, ce n'est pas la première version stable de Qt qui pose des problèmes lorsqu'il s'agit de la compiler sous windows :aie:
Enfin, il se fait que c'est clairement à l'édition de liens que le problème survient.
Et pour te rassurer, ma remarque s'adressait principalement à Mongaulois...
Ma signature te fournira toutes les indications que ma modestie naturelle me pousse à taire ;):D
Hia,
Je pense qu'il y a pas mal de chance que l'erreur vienne du compilateur,
CAR
avec le mingW habituel (gcc version 3.4.2), je compile parfaitement Qt 4.4.0 en release et debug, et ça ne passe pas avec gcc version 4.2.1, avec exactement les mêmes options, des chemins, etc. parfaitement configurés (il sort des âneries comme "symbol not defined in this scope" alors qu'il l'est parfaitement, sinon la version plus ancienne trouverait également la même erreur).
Désolé, j'aurais dû utiliser un smiley; je ne pensais pas à mal ;)Citation:
Envoyé par koala01
Peut-être que Trolltech n'a pas encore géré ce compilo sinon :s
Je parie pour le compilot. Le configure est pour la version 3 de gcc. Peut être quand bidouillant dans le repertoire mkspec, tu pourra modifier win32-g++
Par contre, il y as un topic ou un truc sur mingw-gcc4.3 quelque part? pour voir ce qui est déjà ajouté de c++0x?
ont ils ajouté les rvalue?
OpenMP fonctionne bien?
tu peut aussi repartir de zero(source propre) et essayer
configure -platform win32-g++
pour être sur de configurer pour mingw.
Pour ma part, j'ai tendance à estimer que, si un système compile parfaitement une série non négligeable de bibliothèques, qu'elles soient statiques ou dynamiques, mais "foire" à la compilation d'une bibliothèque unique, c'est sans doute de la faute de la bibliothèque, et non celle du compilateur :DCitation:
Envoyé par droggo
En outre, une erreur de "undefined symbol" reste malgré tout assez facile à résoudre ;)
Citation:
Envoyé par Mongaulois
Tu parle sans doute des rvalues references :question:Citation:
Envoyé par Mongaulois
Selon cette page, ils ont déjà implémenté une première partie (les rvalue references pour tout autre que *this)
Je n'ai évidemment jamais prétendu (bien que mes écrits aient pu laisser croire le contraire) que la prochaine norme était intégralement implémentée...
Et, pour être honnête, il semblerait même qu'il y ait plus de choses qui ne sont pas encore implémentées que de choses qui le sont déjà :aie:
Quant à openMP, j'avoue ne pas avoir testé :aie:
Je suis justement occupé à tenter une compilation lancée de manière tout à fait manuelle... je verrai ce que cela donne ;)Citation:
Envoyé par Mongaulois
Mouais, sauf que la bibliothèque en question dispose d'un certain nombre de réglages compilo "par défaut" par le biais des mkspecs. D'où l'intérêt de savoir dans un premier temps si ça marche en passant par un configure manuel, puis dans un autre, de télécharger les sources et de *tout* faire à la mano.Citation:
Envoyé par koala01
Pas Undefined symbol, "multiple definitions" ;)Citation:
Envoyé par koala01
Edit: grillé, t'as posté entretemps :)
Là, je répondais en réalité à droggo, qui parlait d'un problème de symbol non défini lors de la compilation avec gcc-4.2 :D:DCitation:
Envoyé par IrmatDen
Ca, c'est l'éternelle joie des forums :aie:
Gao,
Certes, mais qu'une ancienne version de ce même compilateur fasse parfaitement bien le travail sur cette même bibliothèque met très sérieusement en doute la version du compilateur, ou alors explique moi pourquoi une telle erreur pourrait passer inaperçue de l'ancienne version, en obtenant des fichiers compilés valides, etc.Citation:
Envoyé par koala01
Et l'idée que l'ancienne version ait pu présenter une manière particulière et "non standard" de fonctionner, et que la bibliothèque ait décidé d'utiliser cette particularité ne t'a visiblement pas effleuré :question:Citation:
Envoyé par droggo
Pour rappel, même avec Gcc3.xx, il y a eu pas mal de versions de Qt qui nécessitaient de redéclarer certaines fonctions parce qu'elles étaient utilisées mais que l'insertion des fichiers ne les prenait pas en compte ;)
Hint: décidé != contourner, trouver un workaround :)Citation:
Envoyé par koala01
Les compilos sont un tel bazar qu'un bug de version est _très_ vite arrivé. De plus Trolltech ne cherche pas à supporter le dernier compilo, ils cherchent à être *cross-platform*. Sinon y'aurait pas mal de chose qui aurait changé comme le fait de ne plus proposer leur propres conteneurs et (quart de set d') algos.
Introduire un comportement 100% standard introduit des bugs, et dans ce cas, personne n'est à blamer; ni le(s) créateur(s) d'une bibliothèque, ni celui/ceux d'un compilo. Les standards évoluent, les compilateurs aussi et les auteurs de bibliothèques doivent se débrouiller pour que ça marche sur les archi cibles; dans le cas de Trolltech, on est loin de la philosophie boost ou gtkmm. Ils *doivent* supporter les vieux compilos buggés.
Trève de débat, quid de la compilation manuelle? :)