Windows porting
Contents
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.
