web-dev-qa-db-fra.com

Comment compiler du code à l'aide de Clang avec la bibliothèque MinGW C / C ++? (Problème particulier avec float.h)

J'ai un programme simple que je peux compiler avec succès avec clang, en utilisant la bibliothèque C/C++ de MinGW:

#include <stdio.h>
int main(int argc, char **argv) { printf("Hello world!\n"); return 0; }

Je suis en mesure de compiler cela avec mingw-gcc avec succès:

 $ gcc test.c -o test
 $ ./test
 Hello world!

Je peux également le compiler avec succès en utilisant clang + mingw:

 $ clang test.c -o test -target
 $ ./test
 Hello world!

Cependant, si j'apporte une petite modification à mon programme (notamment float.h), il continue à compiler avec gcc mais ne compile plus avec clang:

#include <stdio.h>
#include <float.h>
int main(int argc, char **argv) { printf("Hello world!\n"); return 0; }

 $ gcc test.c -o test
 $ ./test
 Hello world!

 $ clang test.c -o test -target x86_64-pc-windows-gnu
 In file included from test.c:2:
 In file included from C:\llvm\built\lib\clang\8.0.0\include\float.h:45:
 C:\mingw64-8.1.0\x86_64-w64-mingw32\include\float.h:28:15: fatal error: 'float.h' file not found
 #include_next <float.h>
               ^~~~~~~~~
 1 error generated.

Y a-t-il un problème de configuration avec clang ou un argument de ligne de commande manquant? En parcourant un peu le contenu, il semble que l'ordre des chemins lors de l'inclusion de float.h soit important, mais tout cela est censé être géré en interne par le pilote clang.

cgccclangmingwllvm
16
Harry Wagstaff

Je pense qu'il serait conseillé de transmettre ce problème à l'un des développeurs de Clang.

La comparaison de la version précédente de float.h de la version 7.1.0 avec celle de 8.0.0 ne montre que quelques différences. La première que je demanderais moi-même, c'est pourquoi ils changent pour le protège-tête de __FLOAT_H à __CLANG_FLOAT_H.

Essayez de changer le protège-tête 8.0.0 et voyez ce qui se passe.

Edit: A fait un peu plus de recherche. Les développeurs MinGW-w64 connaissent cette modification depuis août 2018. Ajoutez ou adaptez le correctif depuis https://sourceforge.net/p/mingw-w64/mailman/message/36386405/ à votre installation MinGW peut le régler.

Edit 2: quelque chose que je n'ai pas utilisé depuis un moment est mon installation MSYS2 de MinGW. Il montre g ++. Exe (Rev1, projet construit par MSYS2) 8.2.1 20181214. Ceci a le patch appliqué à la ligne 27 de float.h.

#if !defined(_FLOAT_H___) && !defined(__FLOAT_H) && !defined(__CLANG_FLOAT_H)

Alors que le téléchargement de forge source de MinGW-w64 8.1.0 l'a montré comme #if !defined(_FLOAT_H___) && !defined(__FLOAT_H)

Remarque: Je suis également sûr que MSYS2 utilise une mise à jour progressive, mais je devrais vérifier cela. Ce n'est pas quelque chose que j'utilise régulièrement.

Edit3: MSYS2 ressemble à une version continue. La dernière version est 9.1.0.

À mon avis, sauf si vous avez besoin d'un MinGW autonome, optez pour MSYS2 avec les dernières mises à jour. Le simple fait d'essayer de corriger l'une des anciennes versions peut fonctionner, mais il peut y avoir d'autres problèmes que je peux montrer eux-mêmes. Si vous avez besoin d'une version autonome, je pense que la seule option serait de construire MinGW-w64 directement à partir de la source.

REMARQUE: j'aurais ajouté des commentaires à la discussion ci-dessus, mais étant nouveau, je ne suis pas encore autorisé.

EDIT 4: REMARQUE: les chaînes d'outils multilib tierces sont plus que probablement construites avec des exceptions sjlj par défaut. Voir https://stackoverflow.com/a/17968530/11879567 sur la façon de vérifier.

Edit 5: J'espère que c'est le dernier montage que je ferai. Consultez les forums MinGW-w64 pour voir si quelqu'un avait demandé quand la prochaine version officielle devait arriver. J'ai rencontré quelqu'un qui m'a demandé quand la version 8.2 devait être publiée. J'ai l'impression que vous pourriez attendre très longtemps pour toute nouvelle version de MinGW-w64. https://sourceforge.net/p/mingw-w64/discussion/723797/thread/ea9a5b00fb/

NOTE LATÉRALE: Comme je l'ai découvert en traitant avec Clang, vous allez toujours avoir un problème ou un autre avec, soit avec MinGW ou Visual Studio.

1
dawlane