Discussion :

[alexgille]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

 > 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) :

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.

[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 ?

[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...

[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)...

[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...

[Médinoc]

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...