Bueno, pues noche a noche estoy intentando portar Bennu a Haiku. Es un poco jodido porque ahora mismo hay una liosa mezcla de librerias compiladas con gcc 2.95 y gcc 4.3. De todas formas ya he conseguido portar el compilador y el interprete, y me estoy pelando ahora con los modulos. Pero si no pasa nada raro deberia de poder, pues las dependencias se cumplen todas.
Un par de cosas para comentar a los mas gurus del tema... como resolveis la dependencia con libdes? en Haiku me he compilado yo mismo la libreria, pero en Linux no esta en los pool de Ubuntu, es eso normal? Y por lo que veo, se usan las utilidades MAP y FPG de fenix no? Podriamos tenerlas en el repositorio tambien. Mi idea es hacer un editor de FPG/Map para Haiku, los formatos de 16/32 bits estan documentados?
En fin, se aceptan sugerencias ! Un saludo
PRG hizo un editor con código bennu, así que si portas bennu ya tienes un editor de fpgs.
En cuanto al código de fpg y map, están disponibles en el CVS del proyecto fenix.
A
lo de libdes, en el código de bennu está el código fuente de éste, además no crea una librería dinámica, sino una librería estática que luego es unida al binario final. Por lo que tengo entendido como es una librería de seguridad, para hacerla más segura lo mejor es no usar una generíca sino bajarte el código fuente, cambiarla un poco y compilar la tuya propia.
En este foro ya hemos debatido alguna vez sobre los formatos de 16 y 32 bits. Yo mismo porté fpgedit, fpg.exe y map.exe a 32 bits.
Pero no tienen ningún misterio si ya conoces el de 8, es solo cambiar el valor de la cabecera que corresponde a la densidad de color y luego tratar los datos de la imagen como:
* 16 bits: array de datos de 16 bits donde el rojo son 5 bit, el verde 6, y el azul 5. Si el dato de 16 bits es un 0, bennu lo interpretará como transparente y no lo dibujará en la pantalla. Este formato es un poco extraño porque el orden de guardado es GBR y porque lo normal es trabajar con valores de componentes de 8 bits para RGB(de 0 a 255), para pasar de 8 bits a 5 hay que hacer un shift de 3 y para pasar a 6 un shift de 2. Asi que: R5= R8 shr 3, G6= G8 shr 2 , B5= B8 shr 3
Como este formato no estaba en DIV el creador de fenix lo diseño así, no se el motivo, pero el creador de CDIV optó por otro formato de 16 bits distinto, no se si porque no le gustaba este o por desconocimiento de él, aunque a nivel práctico la única diferencia entre ellos es la forma de guardar los datos que en esté último lo hace en forma RGB. Bennu no da soporte al formato cdiv.
Yo, para suplir esta pérdida de datos, dí soporte a map.exe, fpg.exe y fpgedit para un nuevo formato de 24 bits para guardar así 8 bits por componente RGB. Pero actualmente ni bennu ni fenix ni ningún divlike da soporte a ellos así que es bastante inútil por ahora :D
* 32 bits: array de datos de 32 bits donde el rojo son 8 bits, el verde 8, el azul 8 y luego hay 8 más para la componente alfa que define cómo de tranlúcido será el bit. Donde 0 es el transparente, los valores intermedios son translúcidos incrementando su opacidad hasta llegar al 255 que es opaco. Esta forma también es la que usan la mayoría de programas y sistemas operativos para guardar o mostrar las imágenes en 32 bits. Esto hace que en el caso de fpgedit este formato sea más rápido a la hora de guardarse y cargarse que el de 16 bits ya que no conlleva preprocesamiento de cada pixel.
Este formato entró con Bennu, desconozco si ge..ix usa el mismo o se ha inventado uno propio.
En cuanto a libdes, en el directorio vendor del svn viene la librería. Para mi repositorio de Ubuntu lo que he hecho es empaquetar la librería. Además, como se compila estáticamente, sólo hay que instalarla si se quiere compilar Bennu.
Yo tuve que compilarme la libiconv tambien para que funcionase en GP2X, pero una vez hecho, cambiando un par de cosillas en el makefile ya debería ir sin problemas (al menos, yo tuve esa suerte, otros no tanto).
Eso si, asegúrate de usar librerías compatibles, que yo lo hice para unas nuevas y cuando los que tenían las consolas con firm oficial (librerías antiguas) lo probaron no les iban.
Cierto lo de libdes, sin problemas para compilar. Por cierto, en el core, hay algun archivo que otro con un encoding maligno :D
No se a qué te refieres...
Quizás sea al código que puso SplinterGU para sus planes de dominar el mundo.
jaja
¿Algún archivo en UTF8?
o quizaz ¿Algúna archivo en formato MS-DOS?
Bueno he conseguido compilar con exito Bennu en Haiku, no obstante hay un par de problemillas. No he modificado nada del codigo, como heredero de fenix ya venia con soporte para plataformas beos-like: -DTARGET_BEOS. Lo que si he hecho es usar otro sistema de construccion, en concreto jam, que es el que usa oficialmente Haiku.
El problema, es que con gcc 2.95 no compila, y falla en un sitio realmente absurdo, de hecho creo que se hace un lio con el encoding. Con gcc 4.3 compila sin problemas. El tema es que Haiku esta compilado contra gcc2, y SDL-gcc4 pues no acaba de funcionar. Y aqui me he quedado, cuando compilo un programa con bgdc , al cargar mod_video.so me da un fallo SDL al no poder resolver una referencia (lo esperado, vaya).
Por suerte, Haiku esta en continuo desarrollo y estoy seguro que en breve habre solucionado el tema de SDL, mientras hablo con los gurus preparare los scripts para instalar y tal.
Que ganas tengo de subir algun screenshot ^ ^
yo, seguiría intentándolo en gcc2, por lo menos hasta que den soporte oficial para gcc4 los de haiku, no es nada dificil cambiar el encoding de los archivos (si es ese el problema) y en cuanto a código c no creo que haya problemas de compatibilidad, por lo poco que ví de código bennu no se sale mucho del standard c.
hay que intentar que compile con el sistema official...
gracias... buen trabajo...
bueno, he usado jam porque todo haiku esta compilado con el, y me aseguraba que los problemas no vendrian por ahi. Con el sistema oficial, he conseguido compilar bgdc y bgdi, pero en el "configure" de los modulos insiste en no encontrar libPNG.
De todas formas, el roadmap es el siguiente:
* que funcione! (supongo que pasara por compilarlo contra gcc2)
* compilar con el sistema oficial
* Herramientas MAP/FPG nativas para Haiku
Vamos a ver hasta donde llego :)
Bueno, necesito un pelin de ayuda. Os cuento...
Como actualmente, Haiku esta compilado con gcc 2.95 con el fin de mantener compatibilidad binaria con Beos, compilar con gcc 4.3 suele traer problemas (en este caso con SDL). Asi que me puse a intentar compilarlo con gcc 2.95, o lo que es lo mismo, standard C89.
El primer problema que me he encontrado es que C89 obliga a que las variables locales se definan al inicio de la funcion. El 95% del código cumple esta regla. Con esto no critico nada! Ciertamente es una regla ya obsoleta (y creo que desaconsejada en C99)
El segundo y mayor problema es el encoding del código fuente. Unos son iso-8859 otros utf-8, otros tienen saltos de linea unix y otros wind0zer. He arreglado la mayoria, pero mod_regex lo he dejado por imposible :C
Solucionado esto, ha compilado y he intentado lanzar un programa de ejemplo. Aqui es donde me he quedado enganchado: Resulta que bgdc me dice que no encuentra las constantes y variables de proceso. Por ejemplo "MODE_WINDOW" o "graph". Tiene toda la pinta de que los modulos no estan exportando estos identificadores... pero doy palos de ciego. Podeis guiarme un poco en este problema? (menos mod_regex y mod_fii ha compilado todo)
Eso es lo nuevo que tiene Bennu con respecto a Fenix, al estar modularizado, necesitas poner imports de los módulos para todas las funciones o variables o constantes que necesites.
Por ejemplo, intenta poner esto al principio del código
import "mod_key"
import "mod_draw"
import "mod_grproc"
import "mod_proc"
import "mod_file"
import "mod_blendop"
import "mod_cd"
import "mod_crypt"
import "mod_effects"
import "mod_map"
Ya lo habia intentado y no funciona, no se que he hecho pero parece que no se estan exportando los simbolos.
¿y están visibles los .so en el path y en el librarypath?
Eso de problemas de exportación es muy raro, si se crearon los so debería ir, tiene que ser mas bién problemas de importación digo yo.
primero tenes que setear la variable LD_LIBRARY_PATH o la equivalente para haiku con el path donde estan las librerias dinamicas...
lo del utf8, lf unix o cr lf windows, deberia corregirse, algunos se escapan... eso deberia ir todo a unix...
si sabes cuales tocaste, avisame asi los corrijo... gracias.
Las librerias esta visibles, de lo contrario bgdc avisa con un "library not found". Es mas, "set_mode" es un simbolo que si es reconocido, pero MODE_WINDOW no. De hecho, si no recuerdo mal, set_mode se define en mod_video y MODE_WINDOW en libvideo, y me parece que el error pueda venir por ahi. ¿Donde se definen las variables del proceso ? : graph, angle, x ,y ...
Por cierto, con encoding diferente hay bastantes, pero vamos, intentar corregir mod_regex que es el que mas guerra da.
Umn, a ver, básicamente haciendo una búsqueda desde el root de svn obtengo que el directorio vendor/des-4.04b es el único que tiene archivos con encoding distinto.
find . -name "*.c" -exec file --mime {} \; | grep -v iso-8859-1
find . -name "*.h" -exec file --mime {} \;| grep -v iso-8859-1
En cuanto a textos msdos o unix sí que hay gazpacho, pero esto creo que es debido al programa svn que uses, si usas el cliente svn oficial hace la conversión directa a windows/unix/mac al descargarte los archivos dependiendo desde el sistema operativo de donde los descargues.
find . -name "*.c" -exec file {} \; | grep -i "with CRLF"
find . -name "*.h" -exec file {} \; | grep -i "with CRLF"
no tenes que hacer import de las libs.... solo de los mod...
Splinter, ¿has probado esos comandos en tu copia local del proyecto?, pueden ayudarte a cambiar los archivos para que tengan el mismo formato, quizas en tu copia local, que es la principal de todas, podrías pasarle un dos2unix recursivamente a todos los archivos y luego subir los cambios a svn.
Si si, hago un import de mod_video nada mas, no obstante sigo sin saber porque no me reconoce constanes y variables. Esta noche seguire haciendo pruebas porque ahora solo doy palos de ciego
Splinter, este sería el primer parseo de los archivos:
find . -name "*" -exec dos2unix {} \;
podrias poner el codigo que estas usando de prueba...
Quote from: DCelso on September 30, 2009, 03:28:55 PM
Splinter, este sería el primer parseo de los archivos:
find . -name "*" -exec dos2unix {} \;
cierto, como no pense en algo tan estupido como eso... gracias.
he estado buscando la manera de hacer lo mismo con el encoding, pero no encuentro comando para cambiar el encoding de un archivo. ¿Sabes de alguno?
iconv
http://www.manpagez.com/man/1/iconv/
Gracias,
segundo parser
find . -name "*" -exec iconv -t ISO-8859-1 {} \;
Bueno, unos meses despues, lo he intentado de nuevo. He visto que ya no dependeis de libdes sino de openssl (que en Haiku ya viene por defecto) y aprecio algun cambio minimo en el sistema de construccion. El caso es que ahora mismo se compila bastante facil en Haiku, simplemente ajustando un par de parametros de entorno y poco mas.
El resultado es el mismo que la ultima vez que lo intente, cuando trato de compilar un programa, aunque estan todos los import y los encuentra (de lo contrario se queja "Not found... mod_blend.so") es incapaz de resolver nombres. Esto es, que no reconoce ninguna constante, como la de las teclas, ni ninguna funcion, set_mode, load_fpg,... pese a estar los import.
Parece obvio que no es un problema de bennu, si no mas bien de Haiku, pero necesito un cable porque estoy dando palos de ciego. ¿Que podria fallar para no poder resolver nombres? ¿De que modulo o libreria depende? ¿Hay alguna ruta de busqueda "hardcoded" en plan /usr/local/...?
Mil gracias por adelantado. Me haria mucha ilusion completar el port
je, ayer mismo pensaba que habia sido de este port...
probaste con el equivalente a LD_LIBRARY_PATH o ldconfig? no se que usa Haiku.
Creo que aún quedan vestigios de mi código de Fenix para BeOS por ahí. ¿Estás compilando con -DTARGET_BEOS o con -DTARGET_LINUX?
Digo porque en BeOS la libdl no era nativa y se usaba la que había hecho alguien y que está todavía en BeBits (http://bebits.com/app/2917). Pero creo recordar que no funcionaba exactamente igual que la versión de Linux. No sé cómo estará el asunto en Haiku.
Me da la impresión, aún así, que la función que está fallandao es la dlibaddr (o quizás _dlibaddr) que están en core/include/loadlib.h y cuando fallan no escriben el error. Prueba a poner un par de fprintf(stderr, "%s\n", __dliberr); antes de los return NULL; en caso de error para saber si el error viene de ahí.
A ver, si los .so no estan en la ruta que toca, bgdc da un error de que no puede encontrar el modulo X.so. Si estan, pero mal compilados tambien sale algun mensaje de unresolved dependency. Con lo cual, las librerias estan correctamente "instaladas", el concepto de instalar en haiku es muy etereo :D
Para compilar, -DTARGET_BEOS, si no se resiste bastante, este flag compila a la primera. para el configure hay que indicar --prefix=/boot/home/config/ y libtool reemplazarlo por el que trae Haiku. El tema de libdl me suena que en Haiku esta mas maduro. No obstante estoy ahora mismo haciendo mas pruebas, ya os dire cosas.
Es que creo que el error que te está dando es otro. A la hora de cargar una librería, primero se abre con dlopen (que es la función que da error si falla) pero luego se buscan los símbolos dentro de esa misma librería, y si esa segunda parte falla, Bennu no da ningún error directo; sólo dice que no puede encontrar la función.
Por eso te digo que si puedes echarle un ojo a ver si es esa función la que está fallando.
Siempre puedes preguntar en la lista de correo de haiku-es (En español) o haiku-os (Ingles) o haiku-dev(inglés tb) en freelists o entrar en #Haiku-os@freenode.org o #Haiku-dev@freenode.org
A ver si algún pro sabe....
También puedes probar a subirlo a Osdrawer como proyecto a ver si alguien se anima (Aunque ahora Haiku ha pegado un subidón que no va por el camino correcto (Según yo), que es eso de portar aplicaciones KDE?) Con todo lo que puede dar de si el nativo :(
xD
Bueno me alegra ver a algún usuario de Haiku por aquí :D
Yo lo uso desde hace tiempo, incluso he subido alguna cosilla a Haikuware :D (Con suerte tenemos Alpha2 este año :D)
Es un problema especifico de bennu, no creo que me puedan ayudar en ningun canal de haiku. Por cierto, el tema de Qt me parece que ya lo discutimos en las listas de haiku-es. Aunque Haiku parezca mas vivo que nunca siguen los mismos programadores de siempre, rozando ya la leyenda, hay que portar lo que sea para acercarlo a la gente, por eso, trato de portar bennu.
Bueno, voy cercando el problema. Siguiendo los consejos de josebita, he añadido algo de verbosidad en las llamadas de carga de librerias. dlopen parece funcionar correctamente, de hecho devuelve un error si los .so no estan instalados. No obstante he puesto fprintfs para ver que pasa en dlibaddr y para mod_video por ejemplo ocurre lo siguiente:
-mod_video_modules_dependency
-mod_video_functions_export
son cargados correctamente, mientras que
-mod_video_constants_def
-mod_video_types_def
-mod_video_globals_def
-mod_video_locals_def
no tienen la misma suerte. Para el resto de modulos pasa algo parecido pero en otro orden. Echandole un ojo a mod_video.c veo que efectivamente, este solo declara una lista de funciones y de dependencias para ser exportado.
bgdc insiste en que "Undefined procedure ("SET_MODE")" :(
Alguna idea de por donde seguir mirando?
esta bien que de error la carga de esos simbolos porque no existen...
podes poner el codigo de ejemplo que estas usando?
Si, eso he deducido, que los errores eran normales, ya que las bibliotecas no publicaban tales simbolos. Supongo que al codigo te referiras al de bennu. Bueno, lo tengo en el portatil del curro, pero ya te digo que cualquiera de los ejemplos falla en la primera funcion, variable o constante que aparezca en el codigo.
Quote from: Lt_Henry on January 31, 2010, 11:18:47 PM
Es un problema especifico de bennu, no creo que me puedan ayudar en ningun canal de haiku. Por cierto, el tema de Qt me parece que ya lo discutimos en las listas de haiku-es. Aunque Haiku parezca mas vivo que nunca siguen los mismos programadores de siempre, rozando ya la leyenda, hay que portar lo que sea para acercarlo a la gente, por eso, trato de portar bennu.
osti quien eres en la lista? xD yo tb escribo ahí xD
Y si, algunos empiezan a rozar el calificativo de "Programador épico" xD
Saludos! A ver si podemos tenerlo entonces en breve xD
no, me refiero al prg de prueba.
[code language="bennu"]
import "mod_blendop";
import "mod_text";
import "mod_grproc";
import "mod_video";
import "mod_map";
import "mod_screen";
import "mod_path";
import "mod_rand";
import "mod_say";
import "mod_mouse";
import "mod_scroll";
import "mod_math";
import "mod_draw";
PROCESS Main()
BEGIN
set_mode(800,600,32);
set_fps (0, 0) ;
END
[/code]
Bueno, este es el código de prueba, falla como no, en set_mode pero vamos, que si pones otra cosa delante falla tambien.