31 juillet 2014

mod_perl ActiveState & MSVC 2013

Après ce mémo sur compilation de Apache 2.2.x avec MSCV 2013 voici la compilation de mod_perl 2.0.x en utilisant le perl de ActiveState. (Avec Strawberry c’est encore plus compliqué car il utilise le compilateur gcc de MinGW)

Le Perl utilisé doit être au minimum 5.8.2 et être compilé avec les options usethreads , useithreads et usemultiplicity.  Pour le vérifier taper: perl –V:uses.+

En théorie il suffit de 4 commandes pour installer mod_perl
perl Makefile.PL MP_AP_PREFIX=\Path\to\Apache2.2.x
nmake
nmake test
nmake install
Malheureusement il y a quelques bugs…


1) Première étape, premier bug

Télécharger les sources de mod_perl 2.0.x ici : http://apache.org/dist/perl/

Assurez vous d’avoir le Perl et le bin de msvc dans le PATH puis, depuis la racine des sources de mod_perl, tapez ces 3 commandes:

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"
set MP_USE_MY_EXTUTILS_EMBED=1
perl Makefile.PL MP_AP_PREFIX=\Path\to\Apache2.2.x


Premier problèmes; Vous n’avez pas la librairie apxs.
Il propose de la télécharger, mais l’url est invalide.

Install apxs now? [yes]
Download of http://perl.apache.org/dist/win32-bin/apxs_win32.tar.gz failed


La bonne url est: https://archive.apache.org/dist/perl/win32-bin/apxs_win32.tar.gz

Il faut éditer le fichier build\win32_fetch_apxs et remplacer
    my $remote = 'http://perl.apache.org/dist/win32-bin/' . $file;
par
    my $remote = 'https://archive.apache.org/dist/perl/win32-bin/' . $file;

Cette fois le commande perl Makefile.PL MP_AP_PREFIX=\Path\to\Apache2.2.x  doit aboutir.


2) Deuxième étape (compilation), deuxième bug

L'étape suivante consiste à exécuter (toujours depuis la racine des sources de mod_perl)
nmake
Mais ça ne marche pas car on obtient :

'C:\Program' is not recognized as an internal or external command, operable program or batch file.
NMAKE : fatal error U1077: 'cd' : return code '0x1'
Stop.


Il faudrait éditer le fichier Makefile et ajouter les quotes au path de MAKE.

MAKE = C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\nmake.exe

mais ce bug est dans tous les Makefile des sous répertoires. Au total cela en fait plus de 60 !

La solution que j’utilise est d'éditer le module \Perl\lib\ActivePerl\Config.pm  et d’ajouter des quotes autour de $prog
for (@make) {
    if (my $prog = _find_prog($_)) {
    $_[0] = $OVERRIDE{$key} = "\"$prog\"";
Mais en ajoutant ces quotes on rend une expression régulière invalide. Il faut éditer \Perl\lib\ExtUtils\MM_Win32.pm et corriger la fonction is_make_type() en supprimant le $ de la fin de l’expression régulière
sub is_make_type {
    my($self, $type) = @_;
    return !! ($self->make =~ /\b$type(?:\.exe)?$/);
}
Avec ces 2 modifs on peut exécuter nmake sans avoir d'erreurs.


3) Troisième étape (tests), troisième bug
nmake test
Le daemon httpd.exe va être exécuté, certains tests ne sont pas exécutés s’il manque des dépendances mais certains vont échouer (en tout cas avec la version mod_perl 2.0.8) !
t/api/err_headers_out.t (Wstat: 0 Tests: 6 Failed: 3)
Failed tests: 2-3, 5
Files=1, Tests=6, 2 

Result: FAIL
Failed 1/1 test programs. 3/6 subtests failed. 

Solution: Dans le fichier t\api\err_headers_out.t il faut remplacer à deux endroits:
  if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
  if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;

Avec ces 2 modifs on peut exécuter nmake test sans avoir d'erreurs.


4) Dernière étape
nmake install
et ça marche (enfin) !



28 juillet 2014

Apache 2.2 & MSVC 2013



La branche 2.2.x du serveur http d’Apache a une importance particulière car mod_perl  y fonctionne correctement ce qui n’est pas le cas avec la nouvelle branche 2.4. Apache 2.2, bien qu'encore supporté, commence à dater. La version 2.2.0 date de décembre 2005. Depuis, les compilateurs ont évolués et des problèmes commencent à apparaitre. C’est le cas avec Visual Studio 2013 et sa « Plateform Toolset v120 ».

Voici ce qu’il faut corriger pour pouvoir compiler le serveur http 2.2 d'Apache avec MSVC 2013.

1) Télécharger

  1. Les sources du serveur http 2.2.xx d’Apache depuis : http://www.apache.org/dist/httpd/ 
  2. Les sources de APR-iconv. Les librairies pcre, APR et AP-utils sont incluses avec les sources de Apache mais pas APR-iconv  car les systèmes Unix fournissent déjà iconv() . Pour Windows ce n’est pas le cas, il faut donc télécharger cette librairie et la mettre dans le répertoire srclib sous le nom apr-iconv (sans aucun numéro de version). On trouve cette librairie ici : https://apr.apache.org/download.cgi 
  3. awk est utilisé pour générer la configuration du serveur (httpd.conf). On peut le télécharger ici  http://sourceforge.net/projects/gnuwin32/files/gawk/ sous le nom de gawk.

 2) Environnement

Le PATH doit inclure un chemin sur awk.exe et sur les binaires de MSVC
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin.

Ouvrir une console (cmd) dans le répertoire contenant les sources d'Apache.

Exécuter le script "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"

3) Compiler

Normalement il suffirait de taper la commande
    nmake -f Makefile.win
mais ça ne marche pas car on obtient 5 erreurs du type:

pr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedXxxx referenced in function _apr_atomic_inc32@xx

Les 5 erreurs sont:

Creating library .\Release\libapr-1.lib and object .\Release\libapr-1.exp
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedIncrement referenced in function _apr_atomic_inc32@4
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedExchangeAdd referenced in function _apr_atomic_add32@8
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedExchange referenced in function _apr_atomic_set32@8
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedDecrement referenced in function _apr_atomic_dec32@4
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedCompareExchange referenced in function _apr_atomic_cas32@12
.\Release\libapr-1.dll : fatal error LNK1120: 5 unresolved externals

NB; Ce problème n’apparait pas si on génère une version 64 bits d’apache.

4) Error LNK2019

Pour corriger cette erreur  il faut éditer le fichier srclib\apr\atomic\win32\apr_atomic.c et mettre en commentaire (ou supprimer)  tous les casts tel que celui-ci (il y en a 9 en tout) :

#else
return ( /*(apr_atomic_win32_ptr_ptr_ptr_fn)*/ InterlockedCompareExchange)(mem, with, cmp);
#endif


(apr_atomic_win32_xxxx) est mis en commentaire 10 fois.
NB: Ceci supprimera les erreurs mais en échange on aura 7 warnings C4047 et 5 warnings C4024 à la compilation.

5) Error LNK2011

A ce stade, si on tentait à nouveau de compiler on obtiendrait cette nouvelle erreur :

adobe-stdenc.obj : error LNK2011: precompiled object not linked in; image may not run
..\Release\iconv\adobe-stdenc.so : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.


Cette erreur, de manière générale, vient du fait que
1.    un fichier xxxx.c est compilé pour créer un fichier xxxx.pch,
2.    ce fichier xxxx.pch est utilisé pour compiler d’autres fichiers .c
3.    au moment de l’édition de lien xxxx.obj n’est pas utilisé
(Détail ici: http://msdn.microsoft.com/en-us/library/3ay26wa2.aspx)

La solution générique a cette erreur consiste donc à ajouter xxxx.obj à la liste des fichiers obj au moment de l’édition des liens.

Dans le cas de Apache 2.2.x, éditer le fichier srclib\apr-iconv\build\modules.mk.win, localiser cette règle et y ajouter la partie surlignée en vert.

.c{$(OUTPUT_DIR)}.so:
    $(SILENT)cl $(ALL_CFLAGS) /Fo$*.obj /Yuiconv.h /c $<
    $(SILENT)link $(ALL_LDFLAGS) $(MODRES).obj $*.obj $(API_LIBS) /out:$@ \
        /base:@"..\build\BaseAddr.ref",$(@F)


Pour comprendre il faut bien voir que $(ALL_CFLAGS) utilisé à chaque compilation contient ... /Fd$(MODRES).pdb /Fp$(MODRES).pch ...

6) Compiler (pour de bon)

Une fois ces erreurs corrigées on peut lancer depuis la racine des sources
  nmake -f Makefile.win   (pour seulement compiler)
ou
  nmake –f Makefile.win installr    (pour compiler et installer dans C:\Apache22)

Le répertoire d’installation peut être spécifié avec le paramètre INSTDIR

  nmake -f Makefile.win INSTDIR="D:\my\Path\Apache" installr

Regardez les commentaires au début du fichier Makefile.win pour découvrir les différents paramètres pouvant être utilisés  pour customiser la compilation et/ou l’installation.

7) Démarrer le serveur HTTPd

Aller dans le répertoire bin de apache (par défaut C:\Apache22\bin) et exécuter httpd.exe






21 juillet 2014

Recherche des lib et dll



Quand on ajoute la librairie XYZ a un projet C/C++ il y a trois informations à donner au compilateur et linkeur :
  1. Le répertoire où se trouve les entêtes des fonctions et classes  (-I /path/to/headers)
  2. Le répertoire où se trouve la librairie (-L /path/to/libs)
  3. Le nom de de la librairie (-l XYZ)
Ce qui est perturbant c’est que bien souvent le nom réel du fichier de cette librairie n’est pas juste ‘XYZ’. En fait quand vous passez l’option "-l XYZ" au linkeur de gcc sous Windows voici, dans l'ordre de recherche, les 7 noms de fichiers qui seront cherché par gcc :





  | "lib" | “XYZ”  | ".dll" | ".a" | ".lib" | Nom cherché
  +-------+--------+--------+------+--------|
1 |   X   |   X    |   X    |  X   |        | libXYZ.dll.a
  +-----------------------------------------|
7 |       |   X    |   X    |  X   |        | XYZ.dll.a
  +-----------------------------------------|
3 |       |   X    |        |  X   |        | XYZ.a
  +-----------------------------------------|
4 |       |   X    |        |      |    X   | XYZ.lib
  +-----------------------------------------|
5 |   X   |   X    |   X    |      |        | libXYZ.dll
  +-----------------------------------------|
6 |       |   X    |   X    |      |        | XYZ.dll
  +-----------------------------------------|
7 |   X   |   X    |        |  X   |        | libXYZ.a
  +-----------------------------------------|


Ceci est répété pour chaque chemin par défaut et pour chaque chemin définit par l'option -L /path/to/libs  jusqu’à ce que l’un de ces 7 noms soit trouvé.

Notez que toutes les combinaisons ne sont pas testées: libXYZ.lib ne sera pas cherché par le linkeur.

17 juillet 2014

GCC Cygwin MinGW and co


GCC est LA suite de compilation du projet GNU, surtout connue pour son compilateur C/C++ mais qui peut aussi compiler Ada, Fortran, Go, Java.

Bien sur on retrouve gcc sur tout les systèmes GNU (bsd, linux) mais aussi sur les Unix propriétaires (Aix, HPUX, MacOS, Solaris ...) et sous Windows. Ce qui fait de gcc LE système de compilation multi plates-formes par excellence.

Sous Windows, même si Microsoft propose, via les éditions “Express”, des versions allégées mais gratuites de sa suite Visual Studio on peut vouloir utiliser un compilateur multi plate-forme, multi langages, open source, avec des mises à jour régulières et conforme aux standards. Dans ce cas gcc est LE bon choix.


GNU GCC sous WINDOWS

Cygwin est une environnement très complet permettant de simuler un environnement POSIX (Unix, Linux, BSD) sous Windows. Les exécutables produits par cygwin/gcc dans cet environnement sont dépendants d’une DLL (cygwin1.dll) émulant l'environnement POSIX sous Windows.

Note : Microsoft Windows Services for Unix (SFU) est un environnement Unix/Posix développé par Microsoft, gratuit mais pas open source, proche de cygwin. SFU 3.5 inclus gcc 3.3. Une version allégée de SFU est incluse dans Win7 Enterprise et Ultimate.


MinGW (Minimalist GNU for Windows) est un portage des principaux outils de développement GNU sous Windows. Les exécutables produits par MinGW/gcc utilisent directement les DLL de Microsoft fournies avec Windows et ne nécessitent pas de couche d’émulation comme avec cygwin.

Actuellement MinGW fonctionne sur Windows 32 et 64 bits mais ne permet de produire que des exécutables 32 bits.

Optionnellement MinGW propose une ligne de commande Unix (bash) et quelques outils du monde Unix (grep, make …). Cet environnement Unix optionnel s’appelle MSYS et est basé sur cygwin mais il ne sert pas à produire des exécutables POSIX comme cygwin. MSYS est juste une facilité pour faire du ‘./configure et make’.

MinGW-w64 est un fork (non voulu) de MinGW. Son gros avantage est de pouvoir produire des exécutables 32 et 64 bits.

TDM-GCC de Twilight Dragon Media et une légère variante et un mix de MinGW et MinGW-w64.
Ces variantes sont principalement de nouvelles options pour gérer les exceptions suivant plusieurs méthodes : SJLJ, DWARF, SEH.

MingGW-builds même buts que TDM-GCC mais plus confidentiel.



GCC et les IDE C++ MULTI PLATE-FORME (Windows, Linux, Mac)

Le compilateur C/C++ de Microsoft fonctionne en ligne de commande mais est surtout réputé pour son interface graphique de qualité : Visual Studio. Mais Visual Studio n’est disponible que sous Windows. Heureusement il existe des environnements de développement graphiques multi plates-formes (Windows, Linux, Mac) utilisant le compilateur C/C++ de gcc. Voici les 3 principaux:

Code::Blocks Le compilateur par défaut pour Windows de Code::Blocks est TDM-GCC mais MinGW/gcc, cygwin/gcc, MSVC, BorlandC++, Watcom sont aussi supportés.

Qt va bien au-delà de l’IDE car il propose aussi une framework pour construire des interfaces graphiques utilisant le même code source sur toutes les plates-formes, y compris Android et iOS. MinGW/gcc et MVSC sont supportés

Eclipse est écrit en java donc plus lourd et plus lent que les IDE natifs. Eclipse est plus un atelier de génie logiciel qu'un simple IDE. Il fonctionne avec de (très) nombreux plugins et supporte ainsi plusieurs langages:  java, C/C++, PHP, SQL ... Le module CDT supporte plusieurs compilateurs dont MinGW/gcc et cygwin/gcc.

15 juillet 2014

Boost + MinGW (Qt, CodeBlock)

Ce n’est malheureusement pas nouveau mais compiler les librairies de Boost sous Windows sans utiliser Visual Studio C++ mais en utilisant MinGW/gcc est une véritable galère !
- Il faut absolument  MASM,  l’assembleur de Microsoft . (celui de gcc n’est pas supporté)
- Il y a 2 bugs dans la batch build.bat qui compile bjam (le ‘make’ de Boost)
- La procédure d’installation/compilation est mal conçue et il faut éditer manuellement des fichiers de configuration.

Nous allons voir comment corriger tout cela...

PREREQUIS
  • MASM est installé. Voir absolument ce post pour éviter de devoir installer MSVC avec MASM.
    MASM doit être dans le PATH.
  • MinGW est installé, soit directement soit via un outil tel que Qt ou Code::Blocks.
    Quelle que soit l’origine de MinGW il faut obligatoirement ajouter au PATH le répertoire ’bin’ de MinGW
  • Télécharger les sources des librairies Boost.

Ce qui suit a été testé avec Boost 1.55 + win7 64bits


PREMIER BUG de tools\build\v2\engine\build.bat.

Le programme d’installation de Boost s’attend à trouver MinGW dans C:\MinGW mais si vous l’avez installé ailleurs, ou utilisez le MinGW de Qt ou CodeBlock ça ne marchera pas.Voici comment corriger cela.

Dans le fichier tools\build\v2\engine\build.bat remplacer (ou mettre en commentaire avec REM) les 4 lignes :
if EXIST "C:\MinGW\bin\gcc.exe" (
   set "BOOST_JAM_TOOLSET=mingw"
   set "BOOST_JAM_TOOLSET_ROOT=C:\MinGW\"
   goto :eof)
Par ces 5 lignes:
call :Test_Path mingw32-make.exe
if not errorlevel 1 (

   set "BOOST_JAM_TOOLSET=mingw"
   set "BOOST_JAM_TOOLSET_ROOT=%FOUND_PATH%..\"
   goto :eof)

Pourquoi  chercher mingw32-make.exe et non gcc.exe dans le PATH ?
- Si on cherche gcc.exe on risque de trouver une installation de gcc qui n’appartient à MinGW mais à cygwin.
- Si on cherche mingw32-gcc.exe on ne trouvera pas gcc si c’est la version 64 bits qui est installée car son nom est  i686-w64-mingw32-gcc.exe
- Réciproquement, si on cherche i686-w64-mingw32-gcc.exe on ne trouvera pas la version 32 bits.
Par contre si on cherche et trouve mingw32-make.exe on est certain qu’avec lui il y a une version de gcc (32 ou 64 bits) appartenant à MinGW.


DEUXIEME BUG de tools\build\v2\engine\build.bat

Ce bug a pour effet de détecter la présence du compilateur de Microsoft MSVC même quand il n’est pas installé. La cause de ce bug est que pour certaines versions de Windows la commande 

    set test=%~$PATH:1

met à jour le errorlevel et pour d’autres non. Ce bug est par exemple présent pour WIN7 64 bits.

Dans la fonction :Test_path, avant la ligne ‘endlocal’ il faut ajouter cette ligne

    if not defined test ( call :Set_Error ) else ( call :Clear_Error )

Ce qui donne :

:Test_Path
REM Tests for the given file(executable) presence in the directories in the PATH
REM environment variable. Additionaly sets FOUND_PATH to the path of the
REM found file.
call :Clear_Error
setlocal
set test=%~$PATH:1
if not defined test ( call :Set_Error ) else ( call :Clear_Error )
endlocal
if not errorlevel 1 set FOUND_PATH=%~dp$PATH:1
goto :eof



TROISIÈME BUG

Une fois ces deux premier bugs corrigés, on peut ouvrir une ligne de commande (cmd) dans la racine des sources de  Boost et taper :

  bootstrap.bat

Ensuite NE PAS TAPER b2 comme indiqué à l’écran !

Il faut au préalable éditer le fichier project-config.jam et remplacer msvc par mingw.

La raison de ce travail supplémentaire est expliqué dans les commentaires du fichier bootstrap.bat :
REM Ideally, we should obtain the toolset that build.bat has
REM guessed. However, it uses setlocal at the start and does
REM export BOOST_JAM_TOOLSET, and I don't know how to do that
REM properly. Default to msvc for now.

set toolset=msvc
Incroyable, n’est-ce pas, qu’après tant d’années personne n’ai trouvé de solution...

Après avoir modifiè project-config.jam vous pouvez exécuter « b2 »


TRUC:

Utilisez "b2 -j 4" pour utiliser 4 theads de compilation, ou plus si votre processeur le supporte.
Pour tout effacer b2 --clean

Plus d'info sur les paramètres de b2...

Après un temps plus ou moins long (de 10 à 50 min) suivant la vitesse cpu et disque de votre machine et le nombre de threads mis en jeux vous obtiendrez  :
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:

    C:/xyz/boost_1_55_0

The following directory should be added to linker library paths:

    C:\xyz\boost_1_55_0\stage\lib


(xyz depend de là où vous avez décompressé Boost)

Bravo !


Boost 1.55 et MSVC 2013 (Quatrième bug)


En compilant Boost 1.55 avec Microsoft Visual Studio Express 2013 (donc version 12) on a cette erreur de compilation:

transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std'
transform_width.hpp(151) : error C3861: 'min': identifier not found


Pour la corriger il faut ajouter cette simple ligne: 
#include <algorithm>
au début de boost/archive/iterators/transform_width.hpp

Il n’y a donc pas que GCC qui est mal testé par les développeurs de Boost !

NB: Je n'utilise Boost que quand c'est imposé car, depuis toujours, c'est la galère.

MASM pour Boost et MinGW

Certaines librairies de Boost contiennent du code écrit en assembleur. Contrairement à C++ qui utilise la même syntaxe quel que soit le système (Linux, Mac, Sun, Windows) l’assembleur n’est pas standardisé. Bien que le processeur soit le même, le même le code ne s’écrit pas de la même façon sous Linux ou Windows parce que l’assembleur par défaut de ces plateformes n’est pas le même.

L'assembleur inclus avec gcc est 'as'. Il est présent sous Windows et Linux mais les mainteneurs de Boost refusent d’avoir deux versions du même code pour la même plateforme. Hors de question pour eux d’avoir une version pour 'MASM' de Microsoft et une autre version pour 'as' de GNU. Pour Windows la seule version disponible est celle pour MASM.

Donc, si vous voulez utiliser la suite gcc de MinGW pour compiler les librairies de Boost il vous faudra malgré tout MASM de Microsoft et, en théorie, une version anglaise de Visual Studio C++ Express Edition. En effet à l’installation de MASM requiert MSVS C++ Express.


En soit rien de grave car les deux produits sont librement et gratuitement téléchargeables chez Microsoft.
Cependant on peut vouloir éviter d’installer toute une suite C++ pour juste pouvoir assembler quelques lignes d’assembleur.  

Voici donc comment installer MASM sans MSVC Express.

Pour cette manipulation on utilisera 7zip : http://www.7-zip.org/
  1. Télécharger MASMsetup.EXE chez Microsoft
    http://www.microsoft.com/en-us/download/details.aspx?id=12654.


  2. Bouton droit sur le fichier qui vient d’être téléchargé,
    dans le sous menu 7-Zip sélectionner « open archive ».

    Ceci ouvrira 7-Zip et vous montrera le contenu du fichier MASMsetup.EXE c’est-à-dire le fichier setup.exe.




  3. Bouton droit sur ‘setup.exe’ puis choisir l’option « Open Inside ».
    Le nom des deux fichier inclus dans setup.exe vont s'afficher.


  4. Bouton droit sur  « vc_masm1.cab » puis à nouveau choisir « Open Inside ».




  5. Un nom de fichier ‘compliqué’ va apparaitre.


     
  6. Faire glisser ce fichier sur le bureau et le renommer « ml.exe »
     
  7. Déplacer ml.exe dans un répertoire présent dans le PATH ou créez en un pour l’occasion.
     
  8. Pour vérifier que tout est ok, ouvrir une ligne de commande (cmd) et taper « ml ». Vous devez obtenir la version du Macro Assembler .



Et voila !