Impossible de compiler libwebsockets avec Visual Studio

Version imprimable

Bonjour à tous,

j'essaye tant bien que mal de compiler la bibliothèque C libwebsockets dans le but d'obtenir une bibliothèque statique Windows (.lib).

Environnement de développement : (disponible sur ce PC)
- Windows 10 x64 (imposé)
- MinGW (PATH)
- MSYS2 x86_64 20160205
- CMake 3.5.2 (PATH)
- Python 2.7.11 (PATH)
- Perl 5.12.4 (PATH)
- Visual Studio 2008
- Visual Studio 2010
- GYP

Sources bibliothèques utilisées :
- openssl-1.0.2h
- libuv-1.8.0 (nécessite GYP)
- libwebsockets-1.7.7

Répertoires :
Sources: C:\tools\<libs_directory_or_tools_path>
Build: C:\tools\build_<libs_directory>

Méthode de compilation :
OpenSSL 1.0.2h
Je suis les instructions fournies dans le fichier INSTALL.W32 de l'archive des sources et je décompresse l'archive avec 'tar xzf xxx.tar.gz' comme stipulé.
Puis je compile avec les commandes suivantes, dans un Invite de Commande Visual Studio 2010:
Code:

1 2 3 4 5 > perl Configure VC-WIN32 no-asm --prefix=C:\tools\build_openssl-1.0.2h > ms\do_ms > nmake -f ms\nt.mak // nt.mak -> lib statique, ntdll.mak -> lib dynamique > nmake -f ms\nt.mak test // Tests OK ! > nmake -f ms\nt.mak install // Install OK !
A part quelques warnings (pourtant curieux) tout compile comme il faut, les tests passent tous et l'installation d'openssl se fait bien dans le répertoire de build dans lequel je retrouve libeay32.lib, ssleay32.lib, openssl.exe, et les headers (.h).

LibUV 1.8.0
J'ai d'abord essayé sur la version 1.9.0, sans succès donc je n'ai pas cherché plus loin, j'ai pris la version 1.8.0.
Ce projet a besoin de GYP pour builder, puis le processus de génération de la solution Visual Studio décrit dans le fichier README.md est simple :

Code:

> vcbuild.dat

Ce qui me donne une solution Visual Studio 2010 uv.sln, que je génère sans problème.

LibWebSockets 1.7.7
Pour aller vite et m'en sortir simplement j'utilise CMake-GUI sur le répertoire des fichiers sources pour générer la solution Visual Studio.
Je donne à CMake-GUI le path des fichiers sources et du répertoire de build, je sélectionne Visual Studio 10 comme générateur et je garde l'option "Use default native compilers" cochée.
Ensuite je configure mon projet avec CMake-GUI, je clique sur "Configure" puis sur "Generate".
J'ouvre la solution fraîchement générée avec Visual Studio 2010 et lorsque je génère la solution j'obtiens une énorme quantité d'erreur du linker (la liste est *très* longue) uniquement pour le projet websocket_shared (.dll) :

Citation:

Extrait de la sortie Visual Studio 2010, la sortie complète est disponible sur demande car trop lourde pour être publiée (704 ko, 8500+ lignes)
[...]
5>------ Début de la génération*: Projet*: websockets_shared, Configuration*: Release Win32 ------
5> Building Custom Rule C:/tools/libwebsockets-1.7-stable/CMakeLists.txt
5> CMake does not need to re-run because C:\tools\build_libwebsockets-1.7-stable\CMakeFiles\generate.stamp is up-to-date.
5>cl : Ligne de commande warning D9002: option '/NODEFAULTLIB' inconnue ignorée
5> base64-decode.c
5> handshake.c
5> libwebsockets.c
5> service.c
5> pollfd.c
5> output.c
5> parsers.c
5>..\libwebsockets-1.7-stable\lib\parsers.c(1469): warning C4018: '>'*: incompatibilité signed/unsigned
5>..\libwebsockets-1.7-stable\lib\parsers.c(1473): warning C4018: '>'*: incompatibilité signed/unsigned
5> context.c
5>..\libwebsockets-1.7-stable\lib\context.c(28): warning C4129: 'c'*: caractère de séquence d'échappement non reconnu
5> alloc.c
5> header.c
5> client.c
5> client-handshake.c
5> client-parser.c
5> ssl.c
5> sha-1.c
5> http2.c
5>..\libwebsockets-1.7-stable\lib\http2.c(170): warning C4018: '<'*: incompatibilité signed/unsigned
5> hpack.c
5>..\libwebsockets-1.7-stable\lib\hpack.c(601): warning C4018: '<'*: incompatibilité signed/unsigned
5> ssl-http2.c
5> lws-plat-win.c
5> server.c
5> Génération de code en cours...
5> Compilation en cours...
5> server-handshake.c
5> extension.c
5> extension-permessage-deflate.c
5> libuv.c
5>..\libwebsockets-1.7-stable\lib\libuv.c(237): warning C4028: paramètre formel 2 différent de la déclaration
5> Génération de code en cours...
5> libuv.lib(loop-watcher.obj) : .netmodule ou module MSIL compilé avec /GL trouvé*; redémarrage de l'édition de liens avec /LTCG*; ajoutez /LTCG à la ligne de commande de l'édition de liens pour améliorer les performances de l'Éditeur de liens
5> Création de la bibliothèque C:/tools/build_libwebsockets-1.7-stable/lib/Release/websockets.lib et de l'objet C:/tools/build_libwebsockets-1.7-stable/lib/Release/websockets.exp
5>libwebsockets.obj : error LNK2001: symbole externe non résolu __localtime64
5>libeay32.lib(mem_dbg.obj) : error LNK2001: symbole externe non résolu __localtime64
5>ssleay32.lib(s3_clnt.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(ssl_asn1.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(d1_srvr.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(d1_clnt.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(s23_srvr.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(s23_clnt.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(ssl_sess.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(s3_srvr.obj) : error LNK2001: symbole externe non résolu __time64
5>libeay32.lib(mem_dbg.obj) : error LNK2001: symbole externe non résolu __time64
5>libeay32.lib(a_time.obj) : error LNK2001: symbole externe non résolu __time64
5>libeay32.lib(bn_rand.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(ssl_lib.obj) : error LNK2001: symbole externe non résolu __time64
5>libwebsockets.obj : error LNK2001: symbole externe non résolu __time64
5>service.obj : error LNK2001: symbole externe non résolu __time64
5>parsers.obj : error LNK2001: symbole externe non résolu __time64
5>libeay32.lib(x509_vfy.obj) : error LNK2001: symbole externe non résolu __time64
5>ssleay32.lib(t1_enc.obj) : error LNK2001: symbole externe non résolu _fprintf
5>ssleay32.lib(d1_both.obj) : error LNK2001: symbole externe non résolu _fprintf
[...]

Voilà. Arrivé ici, je bloque.
Je dispose des headers (.h) pour chacune des lib, ainsi que des bibliothèques (.lib) dont je ne sais pas si elles fonctionnent correctement.

Résultat final de la compilation :
A l'issue de cette compilation j'ai 4 fichiers dans le répertoire de build "Release" :
- websockets.lib
- websockets_static.lib
- zlib_internal.lib
- websockets.exp

Il manque la bibliothèque dynamique (.dll) ce qui est normal.

Lorsque j'essaye de compiler une projet tout simple sous VS2010 avec la lib websockets_static.lib j'obtiens aussi une grosse quantité d'erreurs "symbole externe non résolu" en rapport avec les 3 lib citées plus haut, ce qui me fait penser que la compilation de la lib websocket_static.lib ne s'est peut-être pas bien passé.

Tentatives infructueuses :

Compiler libuv et openssl avec mingw32-make et mingw32-gcc dans sh.exe de MinGW (par désespoir)
Compiler libuv et openssl avec make et gcc sous MSYS2 et MinGW (j'ai bêtement suivi le guide jusqu'à comprendre que ça n'allait pas dans le bon sens)
Générer la solution libwebsockets.sln pour Visual Studio 2008 et essayer de la générer
Ajouter le flag "/GS-" à l'édition des liens pour désactiver la sécurité contre les bufferoverflows
Me faire un café

Si vous avez besoin de plus de détails n'hésitez pas!
Je vous remercie par avance pour votre aide.

04/05/2016, 18h01
Matt_Houston

J'ai lu très vite mais tu compiles la bibliothèque en 32 bits et je vois du 64 un peu partout à l'édition de liens. Est-ce que tu donnes les options adéquates au linker ?
04/05/2016, 18h06
alexgille

A vrai dire j'ai pas vraiment de choix, dans la plupart de ces lib il y a d'abord une première étape automatique de préparation à la compilation (i.e. génération de la solution Visual Studio) puis on compile avec VS ou gcc.
De plus certains outils, comme MSYS2, s'installent automatiquement en 64bits sans même me laisser le choix de l'installer en 32bits. Je sais qu'ici ça n'a rien à voir, mais il y a peut-être d'autres choses automatiquement générées en 64bits sans que je ne le sache...
Mon but dans tous les cas est d'obtenir une lib utilisable sur la majorité des Windows XP, 7 et plus.

Que peut-il manquer à la solution Visual Studio 2010 pour résoudre ce genre de problème, des headers? J'en perd mon latin...
04/05/2016, 20h44
Médinoc

_time64 n'est pas une question de bitness du projet, mais de (contournement du) bug de l'an 2038. Il est normal que les programmes l'appellent quelle que soit leur bitness.

En revanche, il n'est pas normal que cette fonction ne soit pas trouvée, vu qu'elle est dans la C Run-Time Library (CRT)...
04/05/2016, 23h36
alexgille

Ta réponse me fait penser au fait que à cause de problèmes de double déclarations (i.e. le linker qui dit "error [...] already defined in [...]") j'ai dû rajouter l'option /NODEFAULTLIB et configurer VS2010 pour exclure les libs MSVCRT.lib et LIBCMT.lib des libs incluent par défaut.
Je ne sais pas si ça a une influence, mais ça m'a aidé à compiler les libs en règle générale...
05/05/2016, 00h37
Médinoc

Citation:

Envoyé par alexgille

Ta réponse me fait penser au fait que à cause de problèmes de double déclarations (i.e. le linker qui dit "error [...] already defined in [...]") j'ai dû rajouter l'option /NODEFAULTLIB et configurer VS2010 pour exclure les libs MSVCRT.lib et LIBCMT.lib des libs incluent par défaut.
Je ne sais pas si ça a une influence, mais ça m'a aidé à compiler les libs en règle générale...

Ah, le fait de devoir compiler les libs statiques dans le même mode, c'est une plaie.

Mais normalement, on n'en exclut qu'une seule (généralement LIBCMT, et on compile tout ce qu'on contrôle en /MD), pas les deux...
05/05/2016, 11h07
alexgille

Tu me conseilles de faire quoi du coup?
D'après cette page il semblerait que générer avec /MT et d'inclure LIBCMT.lib par défaut serait "logique" pour avoir un link statique de la librairie multithread...
05/05/2016, 11h14
Médinoc

Mais plus personne ne linke statiquement à la CRT, ce n'est pas ce que font les projets par défaut, et avec bonne raison, car ça ne permet pas de bénéficier des MaJ de sécurité de la CRT (même si ça complique l'installation).

Personnellement je conseillerais de recompiler tout ce que tu contrôles en /MD, et d'utiliser /NODEFAULTLIB:LIBCMT pour les autres.
05/05/2016, 11h57
alexgille

J'ai absolument pas la main sur le parc informatique qui utilisera à terme le programme que je crée. Les machines sont situées en Afrique avec un OS allant de Windows XP à Windows 8 et je n'ai que peu de connaissance de l'API Win32 (habitué à compiler sous Unix) ...

Ma question est la suivante : Si j'utilise des .dll, comment les mise à jours dont tu parles vont se faire dans le futur? Elles sont apportées par Visual Studio ou par des "visual c redistributables"?
05/05/2016, 12h32
Médinoc

Une fois les redistribuables installés (et normalement, un projet "déploiement" de Visual Studio peut créer un installeur qui contient à la fois ton programme et les redistribuables), les mises à jour de la CRT viennent par Windows Update.
06/05/2016, 12h51
alexgille

Après avoir recompilé libuv et openssl avec les options "/MD /NODEFAULTLIB:LIBCMT /GS-" sans erreur ni warning, j'obtiens beaucoup moins d'erreurs de LINK lors de la compilation de libwebsockets mais il m'en reste toujours au moment de la compilation de la DLL, ce qui fait planter toute la suite de compilation des EXE de test :

Citation:

5>------ Début de la génération*: Projet*: websockets_shared, Configuration*: Release Win32 ------
5> Building Custom Rule C:/tools/libwebsockets-1.7-stable/CMakeLists.txt
5> CMake does not need to re-run because C:\tools\build_libwebsockets-1.7-stable\CMakeFiles\generate.stamp is up-to-date.
5> base64-decode.c
5> handshake.c
5> libwebsockets.c
5> service.c
5> pollfd.c
5> output.c
5> parsers.c
5>..\libwebsockets-1.7-stable\lib\parsers.c(1469): warning C4018: '>'*: incompatibilité signed/unsigned
5>..\libwebsockets-1.7-stable\lib\parsers.c(1473): warning C4018: '>'*: incompatibilité signed/unsigned
5> context.c
5>..\libwebsockets-1.7-stable\lib\context.c(28): warning C4129: 'c'*: caractère de séquence d'échappement non reconnu
5> alloc.c
5> header.c
5> client.c
5> client-handshake.c
5> client-parser.c
5> ssl.c
5> sha-1.c
5> http2.c
5>..\libwebsockets-1.7-stable\lib\http2.c(170): warning C4018: '<'*: incompatibilité signed/unsigned
5> hpack.c
5>..\libwebsockets-1.7-stable\lib\hpack.c(601): warning C4018: '<'*: incompatibilité signed/unsigned
5> ssl-http2.c
5> lws-plat-win.c
5> server.c
5> Génération de code en cours...
5> Compilation en cours...
5> server-handshake.c
5> extension.c
5> extension-permessage-deflate.c
5> libuv.c
5> Génération de code en cours...
5> libuv.lib(loop-watcher.obj) : .netmodule ou module MSIL compilé avec /GL trouvé*; redémarrage de l'édition de liens avec /LTCG*; ajoutez /LTCG à la ligne de commande de l'édition de liens pour améliorer les performances de l'Éditeur de liens
5> Création de la bibliothèque C:/tools/build_libwebsockets-1.7-stable/lib/Release/websockets.lib et de l'objet C:/tools/build_libwebsockets-1.7-stable/lib/Release/websockets.exp
5>libuv.lib(util.obj) : error LNK2001: symbole externe non résolu _GetProcessMemoryInfo@12
5>libuv.lib(util.obj) : error LNK2001: symbole externe non résolu __imp__GetUserProfileDirectoryW@12
5>libuv.lib(util.obj) : error LNK2001: symbole externe non résolu _GetAdaptersAddresses@20
5>C:\tools\build_libwebsockets-1.7-stable\bin\Release\websockets.dll : fatal error LNK1120: 3 externes non résolus
06/05/2016, 13h03
Médinoc

Sur un vieux SDK, l'import de GetProcessMemoryInfo() est dans PsAPI.lib. GetUserProfileDirectory() nécessite d'importer UserEnv.lib et GetAdaptersAddresses() demande IpHlpAPI.lib.
06/05/2016, 13h28
alexgille

J'ai réussi à compiler libwebsockets complètement sans erreur en rajoutant les libs iphlpapi.lib, psapi.lib, userenv.lib dans les dépendences ...

Maintenant j'ai les libs suivantes :
- libeay32.dll
- ssleay32.dll
- libuv.lib
- websockets.dll

Je vais tester ça plus en profondeur
06/05/2016, 13h33
alexgille

C'est ce que j'ai fait, j'ai trouvé cette info sur MSDN ...

Mais j'ai du mal à comprendre, j'ai sur mon PC les SDKs v5.0, v6.0A et v7.0A. Je trouve les libs de la v6.0A dans "C:\Program Files" et les autres dans "C:\Program Files (x86)"...

Compiler LibUV et OpenSSL avec le flag /MD a résolu le problème, je n'ai pas eu à spécifier une lib à exclure.
Utiliser CMake-GUI m'a aidé à connaitre les infos à fournir pour générer la solution et compiler correctement.
Compiler avec Visual Studio 2010 au lieu de 2008 a été plus simple.
J'ai suivi le conseille de Médinoc de compiler des libs dynamiques car c'est plus flexible et plus facilement maintenable.

Solution rapide :
OpenSSL 1.0.2h
Code:

1 2 3 4 5 > perl Configure VC-WIN32 no-asm --prefix=C:\tools\build_openssl-1.0.2h > ms\do_ms > nmake -f ms\ntdll.mak // nt.mak -> lib statique, ntdll.mak -> lib dynamique > nmake -f ms\ntdll.mak test // Tests OK ! > nmake -f ms\ntdll.mak install // Install OK !
LibUV 1.8.0
Code:

1 2 > cd libuv-1.8.0 > vcbuild.dat release shared
LibWebSockets 1.7.7
Code:

1 2 3 4 5 6 7 8 9 10 11 12 > cd libwebsockets-1.7.7 > mkdir build > cd build > cmake -G "Visual Studio 10" -DOPENSSL_ROOT_DIR=C:\tools\build_openssl-1.0.2h -DOPENSSL_INCLUDE_DIR=C:\tools\build_openssl-1.0.2h\include -DOPENSSL_LIBRARIES=C:\tools\build_openssl-1.0.2h\lib\libeay32.lib;C:\tools\build_openssl-1.0.2h\lib\ssleay32.lib -DLWS_WITH_LWSWS=ON -DLIBUV_INCLUDE_DIRS=C:\tools\build_libuv-v1.8.0\include -DLIBUV_LIBRARIES=C:\tools\build_libuv-v1.8.0\libuv.lib -DCMAKE_INSTALL_PREFIX=C:\tools\build_libwebsockets-1.7.7 ..
Ouvrir la solution Visual Studio créée par CMake dans "build" puis la générer.
Clic-droit sur le projet INSTALL -> Générer, cela va installer l'essentiel dans "C:\tools\build_libwebsockets-1.7.7".

Voilà !
Merci à ceux qui m'ont aidés !