Windows porting

Introducció

En aquest document, parlarem de la viabilitat de portar a terme una modificació en el codi de l'apertium per tal de fer que la plataforma de traducció, desenvolupada pel grup transducens de la Universitat d'Alacant, puga funcionar en sistemes Windows.

Sembla que un dels problemes que impedeixen aquesta compilació en sistemes de Microsoft, siga la manca d'un entorn de compilació lliure, que reconega les cadenes de caràcters amples, això és, que permeta codificacions Unicode.

Per això, diversa gent de la llista de distribució d'apertium, especialment en Jim O'Regan, que n'ha estat treballant, han aportat algunes aproximacions sobre com solventar el problema existent.

Un primer colp d'ull al problema

Aproximacions

Compilació "à la Microsoft".

Aquesta aproximació, pretén compilar el codi de l'Apertium fent servir una cadena d'eines de compilació de programari propietari, com és el compilador de Microsoft Visual C++. Sembla que els intents en aquesta direcció han aconseguit bons resultats en alguns casos. Jimmy O'Regan, entre d'altres, han aconseguit compilar una versió de l'lttoolbox fent servir aquesta aproximació.

Encara que puga semblar un bon camí, seria molt desitjable poder compilar l'Apertium fent servir una cadena d'eines de programari lliure per a la compilació.

Compilació fent servir Cygwin/MinGW

En aquest cas, la idea és fer servir una versió per a Windows d'un compilador lliure (GCC), anomenat MinGW, que al seu torn, ve amb una sèrie d'eines ja portades al windows, necessàries en la majoria dels casos, i que són molt útils per a la compilació (autotools, make, etc.). Aquestes eines fan que la compilació sota windows, siga molt similar a qualsevol compilació estàndard en sistemes UNIX i derivats.

L'inconvenient d'aquesta aproximació és el fet que el MinGW del Cygwin no utilitza la "GNU C Library" (glibc), sinó un subconjunt d'aquesta, anomenada "newlib", que no té suport per a cadenes de caracters amples (wstring), que són emprats de manera prou extesa al codi del projecte.

Aquesta aproximació seria viable, fent servir el MinGW directament, o bé, si es pugués indicar al MinGW del Cygwin que no utilitze la seua biblioteca de C, sinó que puguera ser substituïda per una biblioteca que s'especifique en temps de compilació (per exemple STLPort, disponible a www.stlport.org).

Jim O'Regan està intentant un altre camí. Aquest consistiria en fer servir el TDM GCC (vegeu www.tdragon.net/recentgcc/), que és una nova versió dels compiladors de GNU, que inclou la versió 4.3.2, i que per tant, té suport per a cadenes de caracter ample. Això sembla donar bons resultats, fins on se sap (lttoolbox i altres executables del projecte apertium compilen correctament).

Ara bé, en Jim també diu, que en intentar compilar altres eines de l'apertium, si bé aconsegueix obtindre resultats executables (binaris de Windows), aquests no funcionen de manera correcta, i donen molts problemes en temps d'execució, com errors inesperats, o excepcions, que no ocorren de manera habitual en entorns UNIX.

Això sembla ser degut, al fet que la transmissió (pas) de les excepcions entre mòduls distints no està ben implmentada en MinGW. Sembla ser, però que amb el MinGW basat en GCC 4.4.0, això se solventaria.

Compilació encreuada des de GNU/Linux

Xavi Ivars, ha proposat la idea d'utilitzar un script d'en Volker Grabsch (vegeu-ne la seua plana web), mitjançant el qual, l'entorn de compilació s'aprepara per a produir binaris de windows, amb les llibreries que el propi script descarrega i compila. Això ens assegura que s'estiga emprant les últimes versions dels compiladors GCC, de manera que ens assegurem que implementen característiques com el maneig de cadenes de caracters amples (wstrings) i el pas d'excepcions de manera adequada.

Fer servir una implementació pròpia de wstring

Aquesta última aproximació, va ser proposada pel Mikel Forcada, i consisteix en aplicar un pegat al codi de l'apertium, de manera que no depenga d'una implementació externa de wstring.

Açò seria viable, i una bona solució per al problema de compilació d'apertium en windows, alhora que hauria de permetre compilar de manera normal en la resta de sistemes Unix.

Nous problemes En Jim O'Regan, ha sigut capaç de compilar en Windows, fent servir eines lliures (aproximació amb TDM GCC), si bé, ha tingut problemes en temps d'execució amb els binaris obtinguts, ja que aquests actuen de manera anòmala, segurament per problemes d'enllaç amb biblioteques portades, o per manca de maduresa del compilador emprat. Caldria veure quina és l'arrel del problema.

La raó d'aquest funcionament anòmal en els binaris que s'obtenen, sembla vindre derivada de l'ús i transmissió incorrecte de les excepcions entre mòduls d'apertium i les llibreries externes que aquest enllaça.

Entenent wstring i wchar_t

Introducció

"Pareix que en GNU és normal que wchar_t tinga 32 bits, de manera que es poden guardar codis d'unicode directament, mentres que en alguns sistemes Unix i en Windows, wchar_t té 16 bits i això obliga a usar una codificació UTF-16 / UCS2 d'unicode http://en.wikipedia.org/wiki/UTF-16/UCS-2 (és a dir, si els caràcters estan fora del Basic Multilingual Plane (BMP, http://en.wikipedia.org/wiki/Basic_Multilingual_Plane) d'Unicode, (0000-FFFF), alguns caràcters ocupen 2 wchar_t's. Sol haver-hi un wchar_t.h que explica com es fa ¿no? En l'actualitat cap de les llengües d'Apertium necessita caràcters fora del BMP.

Buscant en google, la recerca "wstring mingw" dóna 2800 resultats de gent que està passant per coses similars." (Mikel Forcada)

Ús de wstring en apertium

Revisant els 42 fitxers que hi ha a la carpeta apertium del projecte apertium al sistema de control de versions, es veu l'existència de 653 aparicions de declaracions de variables de tipus wstring. Amb la qual cosa, es té una primera idea de l'ús que en fa el projecte.

També s'ha revisat la documentació a nivell de codi de l'apertium, gràcies a la documentació en línia disponible (Doxygen). En els grafs de dependències generats, es veu la dependència de la biblioteca STL i del tipus wstring.

Reemplaçant wstring

Existeix, segons comenta Xavi Ivars, una llibreria anomenada ICU (vegeu: http://site.icu-project.org/), que permet l'ús de cadenes Unicode. Caldrà avaluar si permet, mitjançant els tipus que ofereix, reemplaçar l'ús de wstring (wchar_t), l'amplada del qual, és dependent del compilador.

Quick note - wstring is no longer the issue (lttoolbox and most of Apertium compiles with VC++; there's a newer version of MinGW that has wstring support) but it might still be desirable to locate/create a trimmed down version of STL for use on mobile devices (Android/iPhone). There is a remaining issue with MinGW's lack of support for exceptions, however, which can only be addressed by MinGW developers, or by using VC++. I have two patches to fix the remaining issues with VC++ and apertium, but they're so ugly that I haven't wanted to even show them to others. I'll send them to Sergio (hopefully he'll have a better idea) and provide interim binaries as I did with lttoolbox.

I've already changed the various parts of the toolchain to read UTF-8 on Windows (which requires a specific version of Microsoft's C library); if there is an issue with binary compatibility, libapertium's existing UTF-8/16/32 conversion code can be used, so it's a trivial matter to fix it (though I think it's unlikely). -- Jimregan 02:07, 25 July 2009 (UTC)

I checked this today (results on the mailing list) - Windows-compiled dictionaries are identical (at least, for a short example dictionary) -- Jimregan 11:36, 25 July 2009 (UTC)

Bitàcola

19 de juny de 2009

Inicie aquesta bitàcola sobre el projecte de sistemes informàtics, per anar plasmant per escrit els avanços i les idees que vaja tenint.

Consultant el llibre “C++ estándar”, he trobat, parlant de l'Entrada i Sortida (E/S) estàndard per pantalla, que existeixen uns objectes especials wcin i wcout que serveixen per a l'entrada/sortida de caràcters amples.

Tinc el problema d'haver de canviar de sistema contínuament, degut a que no dispose d'un sistema operatiu en què poder provar alhora el funcionament correcte en Windows i GNU/Linux.

Són fiables les màquines virtuals per a fer això? M'imagine que ja ho has intentat --Mlforcada 13:16, 9 August 2009 (UTC)

20 de juny de 2009

He decidit començar per provar a compilar el codi sota un entorn GNU, per comprovar-ne la correcta compilació. He pogut fer-ho bàsicament sense cap esforç, a excepció de la instal·lació d'alguns paquets que en són prerequisit com són flex, libxml, libpcre, etc.

Passe a provar a compilar la documentació. Crec que és el millor pas, tot i que estiga obsoleta, per tractar-se de la versió 2. Necessite documentació més actualitzada. Enviaré un correu a Mikel Forcada.

14 de juliol de 2009

Autoconf i les demés eines de GNU Build donen problemes amb els scripts, que en Linux no donen problemes. En Jim diu que és normal que ocórrega, i proposa que substituïsca: s/dnl/#/g.

És un problema de l'intèrpret de m4? dnl és una ordre m4! --Mlforcada 13:18, 9 August 2009 (UTC)

15 de juliol de 2009

Substituïsc la presència de dnl per #, i autogen.sh s'executa sense problemes.

Sembla que no tinc xmllint instal·lat en l'entorn de compilació de windows, anem a veure d'on el baixem, ja que els enllaços del wiki estan caducats.

libxml / libxslt / zlib http://xmlsoft.org/sources/win32/

Copie libxml2 a c:\msys\1.0

Execute xmllint i "peta" perquè li falta la llibreria libiconv.dll

Descarregue la versió DLL de libiconv des de : http://sourceforge.net/projects/mingw/files/

Descarregue iconv.dll: http://www.dll-files.com/dllindex/dll-files.shtml?iconv

Ara exigeix la presència de zlib1 (que ja teníem descarregada).

xmllint s'executa sense fallades.

Instal·le (copie) ara, libxslt.

Ara es queixa perquè no té flex, el descarregue des de la pàgina SourceForge de MinGW.

Execute flex, i peta, perquè li cal la DLL de regex.

Obtinc una versió que ja tenia descarregada de regex, el fitxer original s'anomena: regex-0.12-MSYS-1.0.11-1.tar.bz2 D'ACORD, ara tinc problemes amb el ./configure, sembla que aquest fitxer generat continga errors, ja que es queixa amb el següent missatge d'error:

lttoolbox:

                 ./configure: line 20144: syntax error near unexpected token `LTTOOLBOX,'
                 ./configure: line 20144: `PKG_CHECK_MODULES(LTTOOLBOX, libxml-2.0 >= required_libxml_version)'

apertium:

                 ./configure: line 20471: test: too many arguments
                 ./configure: line 20908: syntax error near unexpected token `APERTIUM,'
                 ./configure: line 20908: `PKG_CHECK_MODULES(APERTIUM,'

En Jim i en Francis, diuen que això ja havia ocorregut i que havia sigut solventat. El problema sembla ser que els canvis que ells van introduir al SVN han sigut matxacats per alguna versió posterior.

Hauria de comprovar:

               + you have set PKG_CONFIG_PATH and LD_LIBRARY_PATH
               + and the dev libraries for libxml2 and libxslt

He descarregat els fitxers libxml2-devel i libxslt-devel des de: https://nfs-uxsup.csx.cam.ac.uk/pub/windows/cygwin/release-2/libxslt/libxslt-devel/

He extret els fitxers i segueix sense compilar correctament.

En Jim i n'Spectie, no tenen més idees :'(

21 de juliol de 2009

Ahir i hui he estat instal·lant el virtualbox i el WinChiquito 1.2, que és un Windows XP amb característiques reduïdes. Aquest entorn, em permetrà fer proves de la compilació sota windows.

Ja sabia jo que el que havia dit més amunt no era una idea nova --Mlforcada 13:20, 9 August 2009 (UTC)

Ara mateix estic intentant resoldre problemes amb l'accés a internet des de la màquina virtual.

a està corregit, dispose de connexió, i he descarregat el codi des de l'SVN.

Instal·le PCRE.

22 de juliol de 2009

D'acord, ara, que ja tinc un entorn de treball fàcil de restaurar en cas de problemes, continuem. Un problema que crec que potser exisitia, és el fet de no tindre una ruta fins el fitxer de configuració del pkgconfig (PKG_CONFIG_PATH).

Millor descarregar libxml2 i libxslt des de l'adreça: http://www.zlatkovic.com/pub/libxml/ (s'havia caigut la pàgina, l'autor em va contestar un correu dient-me que ja estava operativa).

23 de juliol de 2009

Estic llegint sobre wchar_t, wstring i els problemes que està donant a altra gent. deadbeef (del xat) m'està ajudant amb el problema de l'execució de ./configure.

27 de juliol de 2009

Vaig a reprendre el tema de la documentació de baix nivell (Doxygen), i la seua correspondència amb el codi.

Seguisc investigant sobre la llibreria ICU (http://icu-project.org/), i sobre la amplada dels caràcters wchar_t en els diferents compiladors. Veig, que, la versió de GCC amb suport per a wstring i wchar_t que estem fent servir, dóna 2 quan se li demana pel sizeof(wchar_t). En canvi, la versió de GCC instal·lada en GNU/Linux, ens dóna 4 com a valor.

ICU sembla que siga una bona solució, també ho seria fer servir la llibreria GLib, que té versions per a Windows i GNU, i fa servir un caràcter ample de 4 bytes.

Aquests canvis comportarien "patches" molt extensius? --Mlforcada 13:23, 9 August 2009 (UTC)

4 d'agost de 2009

Segons la nota que ha escrit en Jim en aquest mateix article, pot veure's que ara el problema no és tant el suport de wstring, sinó del maneig d'excepcions. STLPort té suport per a excepcions, així que vaig a compilar-la i intentar enllaçar i compilar apertium així.

M'hauré de documentar perquè no sé quines implicacions té això del maneig d'excepcions --Mlforcada 13:24, 9 August 2009 (UTC)

Jim em comenta que l'únic problema que hi ha hagut fins ara amb el fet d'usar STLPort és que és horrorosa de compilar. Però, s'haurà de provar. A més diu que no n'està segur que el maneig d'excepcions estiga implementat.

Ara mateix cal enllaçar amb msvcrt perquè es fa servir per obligar a usar UTF-8 (mitjançant _setmode).

5 d'agost de 2009

Hem obert un bug al sistema Bugzilla del projecte. Es tracta d'una correcció del maneig dels fitxers temporals sota Windows, es tracta del bug 99 (vegeu: http://bugs.apertium.org/cgi-bin/bugzilla/show_bug.cgi?id=99).

6 d'agost de 2009

Sobre la nota que ha escrit en Jim, sobre el problema actual del maneig d'excepcions, en Mikel m'ha escrit dient que el dissabte, quan dispose d'Internet, podrà pegar-li una ullada al problema que comenta.

9 d'agost de 2009

Vaig a buscar per les pàgines de MinGW, per veure si trobe algú que ja haja tingut el mateix problema amb les excepcions. En Jim diu que n'està fart del MinGW, i que veu molt més viable una compilació amb Visual C++. Això, però no segueix la idea principal d'aquest article, que és aconseguir la compilació amb eines lliures, no només gratuïtes.

Acabe de trobar el següent a barrapunto:

"El equipo de MinGW ha publicado los binarios de GCC 4.4.0 para Windows. De entre las novedades destacan un mejor tratamiento de excepciones, una versión de libstdc++ en forma de librería compartida, y soporte para TLS (thread-local storage), además de todas las novedades de la versión 4.4.0.

Hay que recordar que la anterior versión soportada oficialmente era GCC 3.4.5. Más en reddit. El manejo de las excepciones ha mejorado drásticamente debido a que se ha usado una implementación basada en DWARF, dejando de lado el viejo modelo SJLJ, que ya no estará disponible. Además con esta versión las excepciones ya pueden atravesar las fronteras de las DLL sin problemas."

És possible, que com que no hem fet servir la versió oficial del MinGW, sinó una versió modificada (mod), anomenat TDM, que va eixir abans que la versió oficial i que disposava de suport per a cadenes de wchar_t.

Així que abans de res, pense que s'hauria de provar a fer servir el MinGW oficial amb el GCC 4.4.0, amb suport per a cadenes de wchar_t, i alhora, amb suport per a excepcions implementades amb DWARF, que poden ser capturades, més enllà de les DLLs.

En Jim no m'ha donat resposta sobre aquest tema.

També acabe de veure que a la pàgina de TDM-GCC (http://www.tdragon.net/recentgcc/), ara disposen de dues versions dels compiladors, una amb SJLJ, i l'altra amb DWARF [Hauria de llegir un poc més sobre ambdues].

14 d'agost

Instal·le un nou entorn MinGW amb MSYS, baixant els nous paquets des de la pàgina oficial del MinGW. Instal·laré GCC 4.4.0 (full) Costa trobar alguns dels paquets necessaris, com ara noves versions d'autoconf i automake (les que venen per defecte són antigues segons la majoria de persones del xat).

19 d'agost

Ara que l'entorn ja està plenament operatiu (he trobat tots els paquets que em mancaven), seguisc obtenint problemes amb l'script configure generat:

 ./configure: line 15295: syntax error near unexpected token `LTTOOLBOX,'
 ./configure: line 15295: `PKG_CHECK_MODULES(LTTOOLBOX, libxml-2.0 >= required_libxml_version)'

Dispose de les últimes versions d'aquestes eines, però tot i així seguisc obtenint aquest problema. No sembla haver-hi molta informació en la xarxa. La gent del xat no me'n sap dir la raó. A UNIX i derivats, "simplement funciona".

21 d'agost

En quant al problema, Mikel comenta de canviar la ubicació del fitxer pkg.m4, ha funcionat, el problema del PKG_CHECK_MODULES ja està resolt. Seguim avant.

He hagut de copiar el contingut del fitxer *pkg.m4* en el directori adequat de la màquina virtual /mingw/share/aclocal/.

També he hagut de crear un fitxer .pc en /mingw/lib/pkgconfig/ anomenat libxml-2.0.pc amb el contingut següent:

 # Package Information for pkg-config
 
 prefix=/mingw
 exec_prefix=${prefix}
 libdir=${exec_prefix}/lib
 includedir=${prefix}/include
 modules=1
 
 Name: libXML
 Version: 2.6.32
 Description: libXML library version2.
 Requires:
 Libs: -L${libdir} -lxml2
 Libs.private:  -lz  -lm 
 Cflags: -I${includedir}/libxml2

A més d'això, ara, tot i que el compilador té suport per a wstring, en compilar el test de suport de cadenes de caràcters amples del ./configure, dóna un error:

 $ g++ -ansi -c -Wall -march=i686 -O3 -fomit-frame-pointer -funroll-loops  -L/lib -I/include prova.cpp
 In file included from c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/postypes.h:42,
                  from c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/char_traits.h:42,
                  from c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/string:42,
                  from prova.cpp:1:
 c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:159: error: '::swprintf' has not been declared
 c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:166: error: '::vswprintf' has not been declared

Aïllant el problema hem descobert que es tracta de l'opció -ansi. Cal fer un pegat al configure.ac, per tal que determine la plataforma, i en funció d'això proporcione uns paràmetres (flags) o uns altres, en l'esmentat test.

22 d'agost

He llevat -ansi de les FLAGS de C, CXX i CPP, en el cas que estiguem treballant amb mingw. Això fa que ara puguem executar ./configure i no done error en el test de suport de cadenes de caràcters amples.

Si prove a executar "make", obtinc, però el següent error:

 g++.exe: C:/msys/1.0/mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory

Sembla que en el mateix directori existeix un fitxer anomenat libstdc++.a (sense .dll.a).

24 d'agost

Per resoldre el problema anterior moltes fonts indiquen que només cal modificar el fitxer .la corresponent a libstdc++ en la forma següent:

 library_names='libstdc++_s.a'

(el fitxer libstdc++_s.a si que existeix en el directori actual).

D'aquesta manera es resol el problema, i ara el que ocorre es que ld (l'enllaçador) es queixa, ja que no és capaç de trobar la llibreria XML (libxml2):

 ld.exe: cannot find -lxml2

Resulta que els binaris que vaig descarregar han estat compilats amb Microsoft Visual C++ (MSVC), de manera que són fitxers amb extensió .lib, i no .a i .a.dll com seria necessari. Cal doncs, compilar els binaris pel nostre compte descarregant els fonts des d'xmlsoft.

25 d'agost

La compilació dels fonts de libxml2 dóna errors:

    In file included from libxml.h:33,
                        from threads.c:11:
    ./include/libxml/xmlversion.h:429:1: warning: "ATTRIBUTE_PRINTF" redefined
    In file included from ./include/libxml/xmlversion.h:387,
                        from libxml.h:33,
                        from threads.c:11:
    c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/ansidecl.h:30
    7:1: warning: this is the location of the previous definition
    threads.c: In function 'xmlRMutexUnlock':
    threads.c:415: error: incompatible types when assigning to type 'pthread_t' from
    type 'int'
    threads.c: In function '__xmlGlobalInitMutexDestroy':
    threads.c:534: warning: passing argument 1 of 'DeleteCriticalSection' from incom
    patible pointer type
    c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/winbase.h:128
    9: note: expected 'PCRITICAL_SECTION' but argument is of type 'pthread_mutex_t'
    threads.c: In function 'xmlGetThreadId':
    threads.c:770: error: aggregate value used where an integer was expected
    threads.c: In function 'xmlIsMainThread':
    threads.c:806: error: invalid operands to binary == (have 'pthread_t' and 'pthre
    ad_t')
    threads.c: In function 'xmlCleanupThreads':
    threads.c:903: warning: comparison between pointer and integer
    threads.c:917: warning: passing argument 1 of 'TlsFree' makes integer from point
    er without a cast
    c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/winbase.h:199
    4: note: expected 'DWORD' but argument is of type 'pthread_key_t'
    threads.c:918: warning: assignment makes pointer from integer without a cast
    threads.c: In function 'xmlOnceInit':
    threads.c:947: error: 'run_once' undeclared (first use in this function)
    threads.c:947: error: (Each undeclared identifier is reported only once
    threads.c:947: error: for each function it appears in.)
    threads.c:950: warning: assignment makes pointer from integer without a cast
    threads.c:952: error: incompatible types when assigning to type 'pthread_t' from
    type 'DWORD'
    threads.c: At top level:
    threads.c:991: warning: no previous prototype for 'DllMain'
    threads.c: In function 'DllMain':
    threads.c:996: warning: comparison between pointer and integer
    threads.c:1000: warning: passing argument 1 of 'TlsGetValue' makes integer from
    pointer without a cast
    c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/winbase.h:199
    5: note: expected 'DWORD' but argument is of type 'pthread_key_t'
    threads.c:1004: warning: passing argument 1 of 'TlsSetValue' makes integer from
    pointer without a cast
    c:\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/winbase.h:199
    6: note: expected 'DWORD' but argument is of type 'pthread_key_t'
    threads.c:991: warning: unused parameter 'hinstDLL'
    threads.c:991: warning: unused parameter 'lpvReserved'
    make[2]: *** [threads.lo] Error 1
    make[2]: Leaving directory `/home/libxml2-2.7.3'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/home/libxml2-2.7.3'

Segons es llig a http://n2.nabble.com/libxml2-for-MinGW-gcc-td1437823.html, hi ha maneres de fer servir els binaris (.lib) de libxml:

Sure, there is only a .lib format import library included, but as far
as I know, you can either use that .lib file as such also with mingw,
or use pexports and dlltool to produce a mingw import library for the
libxml2.dll.

--tml

Finalment, faig servir pexports i dlltool per resoldre el problema amb libxml2:

$pexports libxml2.dll | sed s/_//g > libxml2.def
$dlltool --input-def libxml2.def --dllname libxml2.dll --output-lib libxml2.a
$cp libxml2.a /mingw/lib
$ranlib /mingw/lib/libxml2.a

El problema amb libstdc++ NO QUEDAVA RESOLT amb la solució del dia 24. Només cal esborrar el valor de library name del fitxer .la, simplement libtool es fa un embolic tot solet, ja que intenta buscar el valor del fitxer .la abans d'adonar-se que pot fer servir libstdc++ sense més informació.

26 d'agost

Anit, lttoolbox va compilar, va ser necessari, però, llevar les cridades a _setmode, necessàries des de windows, per tal que el SO llija en mode UTF8, i interprete de manera adequada el contingut dels fitxers.

El problema que ens trobem és:

lt_proc.cc:216: error: '_O_U8TEXT' was not declared in this scope

La declaració de _O_U8TEXT es fa en fcntl.h. Però és una declaració que depén de la versió de msvcrt8.dll que es tinga.

En Jim ha proposat, que per solucionar-ho, tornara a ficar la opció de compilació -ansi, però en fer-ho (directament al Makefile), res no ha canviat. El compilador segueix dient que _O_U8TEXT no està declarat.

Una altra opció seria, fer que desde el configure es declare __MSVCRT_VERSION__ amb un valor igual o major que 8, per tal que l'avaluació de l'#if que precedeix la declaració de _O_U8TEXT en fcntl.h, siga positiva.

Això últim deixa que el programa compile correctament, però no evita que, donat un fitxer amb la cadena "Hola món", lt-proc (per exemple) la llija de manera incorrecta. S'etiqueta la paraula Hola i la lletra m de la paraula món:

$ cat fitxer.txt | lt-proc ca-en.automorf.bin
^Hola/Hola<ij>/Hola<n><f><sg>$ ^m/*m$├│

Jim proposa fer que s'indique a l'enllaçador de manera adequada la versió de msvcrt.dll (Microsoft Visual C/C++ Runtime), com s'explica ací: http://www.mingw.org/wiki/SpecsFileHOWTO#comment-106 :

(...) here is a method for utilising a version of MSVCRT.DLL, other than the default, (say MSVCR80.DLL), on demand (...)

Vegeu també

• Apertium and Windows