Première question, quel forum serait le plus approprié pour ce type de question
? (et donc désolé pour la "pollution")
Deuxième question, la vraie donc:
J'essaye d'installer Qt4.0.1 open source sous winxp avec mingw g++ et après bien
des problèmes ça a bien fonctionné jusqu'à la compilation des libs xml.
J'ai demandé une compilation debug-and-release et si la debug fonctionne, pour
la release j'ai plein de lignes de ce type :
tmp\obj\release_shared\qxml.o(...:qxml.cpp: undefined reference to `...'
Quelqu'un a une suggestion ? Le répertoire qui contient les libs est pourtant
bien indiqué dans la commande de compilation.
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
je me demande si bêtement quand on écrit
g++ ... -lmachin
sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!?
( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
Aurelien Regat-Barrel
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
-- Aurélien Regat-Barrel
je me demande si bêtement quand on écrit
g++ ... -lmachin
sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!?
( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à
l'exécution, pas à la compilation.
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
-- Aurélien Regat-Barrel
Matthieu Moy
Aurelien Regat-Barrel writes:
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que pour vérifier que tous les symboles seront là à l'éxécution). Enfin, en tous cas, c'est le cas sous Linux.
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à
l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que
pour vérifier que tous les symboles seront là à l'éxécution). Enfin,
en tous cas, c'est le cas sous Linux.
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que pour vérifier que tous les symboles seront là à l'éxécution). Enfin, en tous cas, c'est le cas sous Linux.
-- Matthieu
Aurelien Regat-Barrel
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que pour vérifier que tous les symboles seront là à l'éxécution). Enfin, en tous cas, c'est le cas sous Linux.
J'avais la flemme d'écrire édition de liens... :-) Il utilise le .a (.lib en fait) pour générer le table d'import des symboles. C'est le loader de Windows qui vérifie que tous les symboles importés sont bien présents dans la dll au moment de l'exécution.
-- Aurélien Regat-Barrel
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à
l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que
pour vérifier que tous les symboles seront là à l'éxécution). Enfin,
en tous cas, c'est le cas sous Linux.
J'avais la flemme d'écrire édition de liens... :-)
Il utilise le .a (.lib en fait) pour générer le table d'import des
symboles. C'est le loader de Windows qui vérifie que tous les symboles
importés sont bien présents dans la dll au moment de l'exécution.
Il me semble qu'il cherche libmachin.a. La dll est nécessaire à l'exécution, pas à la compilation.
A la compilation, non. Au link, oui, il en a besoin (ne serait-ce que pour vérifier que tous les symboles seront là à l'éxécution). Enfin, en tous cas, c'est le cas sous Linux.
J'avais la flemme d'écrire édition de liens... :-) Il utilise le .a (.lib en fait) pour générer le table d'import des symboles. C'est le loader de Windows qui vérifie que tous les symboles importés sont bien présents dans la dll au moment de l'exécution.
-- Aurélien Regat-Barrel
Aurélien Barbier-Accary
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une mauvaise piste et mon problème reste entier ;-( En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une
mauvaise piste et mon problème reste entier ;-(
En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une mauvaise piste et mon problème reste entier ;-( En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
fraca7
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
En fait d'aprés ma propre expérience, les versions récentes de MINGW linkent de préférence avec le .a s'il est présent, sinon il essaye avec le .lib mais ça ne fonctionne pas toujours trés bien... Pour convertir un .lib en .a, il faut récupérer pexports.exe et faire ça:
je me demande si bêtement quand on écrit
g++ ... -lmachin
sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!?
( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
En fait d'aprés ma propre expérience, les versions récentes de MINGW
linkent de préférence avec le .a s'il est présent, sinon il essaye avec
le .lib mais ça ne fonctionne pas toujours trés bien... Pour convertir
un .lib en .a, il faut récupérer pexports.exe et faire ça:
je me demande si bêtement quand on écrit g++ ... -lmachin sous windows le compilo ne cherche pas machin.so au lieu de machin.dll ?!? ( je "débute" sous windows, c'était plus simple sous linux ! ;-p )
En fait d'aprés ma propre expérience, les versions récentes de MINGW linkent de préférence avec le .a s'il est présent, sinon il essaye avec le .lib mais ça ne fonctionne pas toujours trés bien... Pour convertir un .lib en .a, il faut récupérer pexports.exe et faire ça:
Là tu génères un .a à partir d'une dll (et non une conversion .lib -> .a). Les .a sont en fait des .lib au format COFF, le même format que VC++. Les utilitaires de VC++ (dumpbin...) fonctionnent dessus. Ca veut aussi dire que tu peux prendre un toto.lib de VC++, le renommer en libtoto.a et linker avec... en C en tous cas. En C++, avec la différence de name mangling ça ne passera pas.
-- Aurélien Regat-Barrel
Pour convertir
un .lib en .a, il faut récupérer pexports.exe et faire ça:
Là tu génères un .a à partir d'une dll (et non une conversion .lib ->
.a). Les .a sont en fait des .lib au format COFF, le même format que
VC++. Les utilitaires de VC++ (dumpbin...) fonctionnent dessus.
Ca veut aussi dire que tu peux prendre un toto.lib de VC++, le renommer
en libtoto.a et linker avec... en C en tous cas. En C++, avec la
différence de name mangling ça ne passera pas.
Là tu génères un .a à partir d'une dll (et non une conversion .lib -> .a). Les .a sont en fait des .lib au format COFF, le même format que VC++. Les utilitaires de VC++ (dumpbin...) fonctionnent dessus. Ca veut aussi dire que tu peux prendre un toto.lib de VC++, le renommer en libtoto.a et linker avec... en C en tous cas. En C++, avec la différence de name mangling ça ne passera pas.
-- Aurélien Regat-Barrel
fraca7
Pour convertir un .lib en .a, il faut récupérer pexports.exe et faire ça:
En C++, avec la différence de name mangling ça ne passera pas.
C'est vrai, j'avais oublié :)
Casillux
Aurélien Barbier-Accary wrote:
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une mauvaise piste et mon problème reste entier ;-( En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher tout seul... Peut être en reessayant depuis le début ça passera (en désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas compilé en debug...
Aurélien Barbier-Accary wrote:
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une
mauvaise piste et mon problème reste entier ;-(
En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun
problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher
tout seul... Peut être en reessayant depuis le début ça passera (en
désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas
compilé en debug...
ok, ça me parait plus logique comme ça mais du coup il s'agit donc d'une mauvaise piste et mon problème reste entier ;-( En tous cas merci pour vos réponses.
Personne n'a essayé d'installer Qt4 pour windows sur ce forum ?
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher tout seul... Peut être en reessayant depuis le début ça passera (en désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas compilé en debug...
Aurélien Barbier-Accary
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher tout seul... Peut être en reessayant depuis le début ça passera (en désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas compilé en debug...
Merci, c'est déjà bien de savoir que ça peut marcher. Moi 'avais déjà un compilateur installé et tout configuré pour mes besoins donc je n'ai pas utilisé l'installeur et j'ai préféré la version .zip à compiler soi même. Mais j'y arriverai :-)
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun
problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher
tout seul... Peut être en reessayant depuis le début ça passera (en
désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas
compilé en debug...
Merci, c'est déjà bien de savoir que ça peut marcher.
Moi 'avais déjà un compilateur installé et tout configuré pour mes besoins donc
je n'ai pas utilisé l'installeur et j'ai préféré la version .zip à compiler soi
même.
Mais j'y arriverai :-)
Ben oui j'ai déjà essayé et ça a marché parfaitement sans aucun problème. J'avais téléchargé la version qt qui installait aussi mingw++.
Je sais que ça n'aide pas, désolé, juste pour dire que ça peut marcher tout seul... Peut être en reessayant depuis le début ça passera (en désinstallant le compilateur+qt et en les réinstallant.
NB : je n'ai compilé qu'en mode release (par défaut), je n'ai pas compilé en debug...
Merci, c'est déjà bien de savoir que ça peut marcher. Moi 'avais déjà un compilateur installé et tout configuré pour mes besoins donc je n'ai pas utilisé l'installeur et j'ai préféré la version .zip à compiler soi même. Mais j'y arriverai :-)