0
J'essaie de compiler un programme C++ et j'ai quelques problèmes. En particulier, quand j'utilise x86_64-w64-mingw32-gcc comme compilateur, il se plaint à mi-chemin de ma compilation en disant "tmp/src/libfastms/solver/solver.cpp.o: fichier non reconnu: format de fichier non reconnu".MinGW compilation "fichier non reconnu: format de fichier non reconnu"
Voici mon makefile (pas le mien, je suis en train d'adapter ce makefile à un environnement Cygwin) https://pastebin.com/vgnVYJUL
est ici la sortie de la console quand je lance make:
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver.cpp.o src/libfastms/solver/solver.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_base.cpp.o src/libfastms/solver/solver_base.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_host.cpp.o src/libfastms/solver/solver_host.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/has_cuda.cpp.o src/libfastms/util/has_cuda.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/image_mat.cpp.o src/libfastms/util/image_mat.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
ld -r -o tmp/src/libfastms/libfastms.o tmp/src/libfastms/solver/solver.cpp.o tmp/src/libfastms/solver/solver_base.cpp.o tmp/src/libfastms/solver/solver_host.cpp.o tmp/src/libfastms/util/has_cuda.cpp.o tmp/src/libfastms/util/image_mat.cpp.o
tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized
Makefile:167: recipe for target 'tmp/src/libfastms/libfastms.o' failed
make: *** [tmp/src/libfastms/libfastms.o] Error 1
D'autres notes :
- Je n'ai pas ce problème quand je compile avec g ++ (semble seulement être MinGW)
- Une solution commune à ce problème est de nettoyer le répertoire des fichiers d'objets résiduels. Cela ne fonctionne pas.
- Une autre raison courante est d'essayer de compiler des fichiers .h. Évidemment, je ne fais pas ça.
Merci d'avance.
Je ne suis pas familier avec la construction sur Windows, mais je soupçonne que votre problème est que l'éditeur de liens essaie de lier un programme 32 bits, et vous lui donnez des fichiers objets 64 bits. Pourquoi utilisez-vous 'ld' directement pour lier votre programme? Pourquoi n'utilisez-vous pas 'x86_65-w64-mingw32-gcc' en tant que frontal pour l'éditeur de liens? C'est la manière traditionnelle de lier les choses et cela fonctionne presque toujours mieux puisque le frontal du compilateur sait quelles options supplémentaires spéciales doivent être apportées à l'éditeur de liens. Est-ce que l'option '-shared' fonctionne sur minGW? Si vous devez utiliser 'ld', vous aurez probablement besoin de savoir comment lui dire d'utiliser des objets 64 bits. – MadScientist
Salut. Merci pour la réponse. Comme je l'ai mentionné, je modifie le makefile de quelqu'un d'autre afin de compiler ce programme pour Windows.Au lieu d'utiliser ld comment pourrais-je aborder le problème? Est-ce que j'appellerais simplement x86_65-w64-mingw32-gcc -o? Aussi, excusez mon manque d'expérience, d'après ce que je comprends, x86_65-w64-mingw32-gcc est un compilateur 64 bits alors pourquoi essayerait-il de lier un programme 32 bits? –
Les compilateurs 64 bits peuvent généralement générer du code 32 bits et 64 bits. Intel 32 bits est essentiellement un sous-ensemble de 64 bits. Pour quelque raison que ce soit, Windows a toujours été utilisé par les compilateurs pour générer du code 32 bits par défaut, sauf indication contraire. Ainsi, une commande 'ld' brute attendra de générer 32 bits. Quant à votre autre question, Mike Kinghan a fourni des détails dans sa réponse. – MadScientist