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 MinGW 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, només si es pugués fer servir el MinGW, sense que 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.

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

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.

No sóc capaç d'avaluar, a dia de hui, quina és la raó d'aquest funcionament anòmal en els binaris que s'obtenen. Caldria veure si la raó és haver emprat una versió massa recent d'un compilador inestable, o si bé, el codi del projecte presenta dificultats afegides a l'hora de compilar (altres manques).

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.

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.

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.

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.

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

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.

Vegeu també

• Apertium and Windows