LG

Dans ce cas, il s'agit d'une erreur dans l'entête libintl.h et qui a été corrigé depuis gettext_ make libintl.h compatible with Visual Studio. · Alexpux_MINGW-packages@b78ab10 · GitHub Archive du 15/06/2019 le 30/10/2019. Cette modification permet à Visual Studio de considérer la fonction libintl_printf comme étant celle native du système __printf__. La question peut se poser pour savoir si cette situation était volontaire afin de forcer VS à utiliser une autre fonction que celle de base mais je ne suis pas parvenu à trouver un fichier .a qui contenait sa définition.

Dans le présent cas, il s'agit d'une dépendance manquante d'une librairie de msys2. Dans ce cas, il est nécessaire d'ajouter les dépendances manquantes.

L'objectif ici est de décrire la méthode pour les trouver. Tout d'abord, il convient de les chercher dans 3 dossiers dans le cas d'une application 32 bits :

• C:\msys64\mingw32\lib
• C:\msys64\mingw32\i686-w64-mingw32\lib
• C:\msys64\mingw32\lib\gcc\i686-w64-mingw32\4.9.2

et pour les applications 64 bits :

• C:\msys64\mingw64\lib
• C:\msys64\mingw64\x86_64-w64-mingw32\lib
• C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2

Attention : interdiction formelle de prendre dans le dossier C:\msys64\usr\lib qui sont les librairies nécessaires pour faire tourner msys2.

Ensuite, il est nécessaire d'extraire tous les symboles de l'ensemble des fichiers .a. Pour cela la commande nm devra être exécuté dans chaque dossier : nm -s --defined-only *.a > list.txt.

Pour résoudre la dépendance __imp___iob il convient de trouver toutes les occurrences dans les symboles des fichiers .a. Les solutions sont dans

• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libcrtdll.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr100.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr110.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr120.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr120d.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr80.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr90.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcr90d.a
• C:\msys64\mingw64\x86_64-w64-mingw32\lib\libmsvcrt.a

Utilisant Visual Studio 2015 (v14), le fichier correspondant à ma version est manquant. Il ne reste plus que libcrtdll.a et libmsvcrt.a. Les deux fichiers permettant de résoudre la dépendance, il sera plutôt choisi libcrtdll.a afin d'éviter de possibles problèmes avec le fichier msvcrt.lib de Visual Studio.

Ici le problème est similaire au précédent. Le fichier contenant le symbole est C:\msys64\mingw32\i686-w64-mingw32\lib\libmingwex.a. Malheureusement, 4 nouveaux symboles indéfinis apparaissent : ___mingw_raise_matherr, ___chkstk_ms, ___umoddi3 et ___udivdi3.

Après recherche :

• ___chkstk_ms, ___umoddi3 et ___udivdi3 seront trouvés dans C:\msys64\mingw32\lib\gcc\i686-w64-mingw32\4.9.2\libgcc.a,
• ___mingw_raise_matherr sera trouvé dans C:\msys64\mingw32\i686-w64-mingw32\lib\libmingw32.a mais un nouveau message d'erreur apparait : _atexit already defined in libmingw32.a(lib32_libmingw32_a-atonexit.o) dans le fichier MSVCRTD.lib(utility.obj)

Pour résoudre ce dernier point, pas moyen de faire les choses proprement. Appliquer la méthode Linker Tools Error LNK2005 Archive le 11/04/2016 le 30/10/2019 en ajoutant au lieur l'option /FORCE:MULTIPLE. C'est sale, il faut impérativement réaliser des tests pour s'assurer que le lieur n'a pas fait n'importe quoi mais félicitation, vous avez votre librairie.

Cela ne peut être fait directement car la façon dont le lieur de gcc et de Microsoft converti le nom de fonction en symbole est différent (mangling). Deux articles couvrent bien le sujet.

Linking MSVC Libraries with MinGW Projects _ Out of Hanwell Archive du 01/05/2006 le 30/10/2019

MSVC and MinGW DLLs _ MinGW Archive du 26/02/2009 le 30/10/2019