IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bibliothèques, systèmes et outils C Discussion :

Impossible de compiler libwebsockets avec Visual Studio


Sujet :

Bibliothèques, systèmes et outils C

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut Impossible de compiler libwebsockets avec Visual Studio
    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 :

    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.

  2. #2
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 182
    Points
    4 182
    Par défaut
    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 ?

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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...

  4. #4
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 190
    Points : 40 749
    Points
    40 749
    Par défaut
    _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)...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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...

  6. #6
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 190
    Points : 40 749
    Points
    40 749
    Par défaut
    Citation Envoyé par alexgille Voir le message
    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...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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...

  8. #8
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 190
    Points : 40 749
    Points
    40 749
    Par défaut
    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.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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"?

  10. #10
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 190
    Points : 40 749
    Points
    40 749
    Par défaut
    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.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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 :

    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

  12. #12
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 190
    Points : 40 749
    Points
    40 749
    Par défaut
    Sur un vieux SDK, l'import de GetProcessMemoryInfo() est dans PsAPI.lib. GetUserProfileDirectory() nécessite d'importer UserEnv.lib et GetAdaptersAddresses() demande IpHlpAPI.lib.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  13. #13
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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

  14. #14
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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)"...

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 112
    Points : 90
    Points
    90
    Par défaut
    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 : 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\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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    > cd libuv-1.8.0
    > vcbuild.dat release shared
    LibWebSockets 1.7.7
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Compiler openExr avec visual studio 2008
    Par elanari dans le forum Visual Studio
    Réponses: 0
    Dernier message: 08/04/2011, 12h03
  2. Réponses: 4
    Dernier message: 10/11/2007, 14h59
  3. compilation OpenMASK avec visual studio 2005
    Par twix24 dans le forum Développement 2D, 3D et Jeux
    Réponses: 0
    Dernier message: 01/10/2007, 22h45
  4. Compilation avec Visual Studio 2005
    Par LordBob dans le forum MFC
    Réponses: 3
    Dernier message: 14/04/2006, 20h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo