LG

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
La compatibilité entre Visual Studio et MinGW (msys2) est tout un art où seules de très longues heures de recherche et une pointe de bricolage sont souvent nécessaires.

La compilation n'est généralement pas vraiment un problème, hormis quelques différences mineures. Cependant, si l'on souhaite lier un programme compilé avec VS et les librairies de MinGW, c'est tout une autre paire de manches. Mais il est souvent préférable de passer du temps pour trouver un moyen de faire de l’interopérabilité plutôt que de se forcer à compiler de nombreuses librairies avec VS ce que n'est pas toujours facile et généralement non suivi des versions futures.

=====unresolved external symbol _libintl_printf referenced in function …=====
Dans ce cas, il s'agit d'une __erreur dans l'entête__ ''libintl.h'' et qui a été corrigé depuis [[https://github.com/Alexpux/MINGW-packages/commit/b78ab10709fcda1c4220a4b2fbc7607293238656|gettext_ make libintl.h compatible with Visual Studio. · Alexpux_MINGW-packages@b78ab10 · GitHub]] {{ :probleme:liaison:mingw_vs:gettext_make_libintl.h_compatible_with_visual_studio._msys2_mingw-packages_b78ab10_github_2019-10-30_15_54_16_.html |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.

=====unresolved external symbol __imp___iob referenced in function …=====
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.

=====unresolved external symbol ___mingw_vprintf referenced in function …=====
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 [[https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k%28LNK2005%29&rd=true|Linker Tools Error LNK2005]] {{ :probleme:liaison:mingw_vs:linker_tools_error_lnk2005_microsoft_docs_2019-10-30_15_55_25_.html |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.

=====Lier des dlls MinGW avec Visual Studio=====
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 ([[lang:cpp:lieur|mangling]]). Deux articles couvrent bien le sujet.

[[https://outofhanwell.wordpress.com/2006/05/01/linking-msvc-libraries-with-mingw-projects/|Linking MSVC Libraries with MinGW Projects _ Out of Hanwell]] {{ :probleme:liaison:mingw_vs:linking_msvc_libraries_with_mingw_projects_out_of_hanwell_2019-10-30_15_55_33_.html |Archive du 01/05/2006 le 30/10/2019}}

[[http://www.mingw.org/wiki/msvc_and_mingw_dlls|MSVC and MinGW DLLs _ MinGW]] {{ :probleme:liaison:mingw_vs:msvc_and_mingw_dlls_mingw_2019-10-30_15_55_39_.html |Archive du 26/02/2009 le 30/10/2019}}