Como lo prometido es deuda, aqui esta el modulo que prometi para esta noche :)
El famoso expand.dll de Fenix, ahora en Bennu: mod_expand :)
Por algun tiempo pensé que DCElso se adelantaba, ya que incluso Drumpi dijó su nombre!!!
Pero sobretodo doy las grácias a DCElso sin el cual no era posible, ya que me dio las pistas para resolver las dudillas base :)
Que lo disfruteis, mañana con más tiempo la preparo como debe de ser, con un ejemplo y claro con todo el src incluido.
Grácias amigos, da gusto pertenecer a esta comunidad :)
(http://forum.bennugd.org/index.php?action=dlattach;topic=1227.0;attach=942)
Pongo el código y la imagen por si no la teneis para probar:
PROGRAM Expand;
private
xS[3]; //Coordenadas de las eskinas
yS[3];
vert,select;
begin
//full_screen = false;
//graph_mode = mode_16bits;
//set_fps(0,0);
set_mode(320, 240, 32);
set_fps(60, 0);
write_int(0,0,0,0,&fps);
graph = load_png("Homer.png");
write(0,21,29,4,"1");
write(0,139,29,4,"2");
write(0,139,171,4,"3");
write(0,21,171,4,"4");
write(0,160,10,4,"Utiliza 1,2,3,4 para elegir");
write(0,160,20,4,"vértice y cursores para moverlo");
write(0,160,190,4,"Vértice elegido:");
write_int(0, 220, 190, 4, &vert);
x = 80;
y = 100;
xS[0] = xS[3] = 181;
xS[1] = xS[2] = 299;
yS[0] = yS[1] = 29;
yS[2] = yS[3] = 171;
loop
if (key(_1)) select = 0; end
if (key(_2)) select = 1; end
if (key(_3)) select = 2; end
if (key(_4)) select = 3; end
if (key(_left)) xS[select]--; end
if (key(_right)) xS[select]++; end
if (key(_up)) yS[select]--; end
if (key(_down)) yS[select]++; end
vert = select+1;
map_clear(0,0,0);
expand(file, graph, xs[0], ys[0], xs[1], ys[1], xs[2], ys[2], xs[3], ys[3], 0, 0);
if (key(_esc)) exit(0,0); end
frame;
end
end
Ottia, mola: karma up (no te quejarás, el se lleva el pack semanal, pero tu haces doblete en un día).
Esta es una de las características en las que nos ganaba flash, por su facilidad a la hora de deformar imágenes, ahora no hay excusas (y si se sabe usar bien, se pueden lograr efectos 3D curiosos con el manejo 2D).
Lo cierto es que en su día no la probé a fondo, por lo que no se hasta qué punto queda bien, pero si se le añade el soporte 32bits... yo creo que se podría babear.
Vamos, porque no se qué opinará Tristán de esto, pero yo por mi, casi pediría que fuese una lib oficial (VSE también, si se arregla ;D).
umn, pero esto ¿no lo hace ya vse? o eso lo entendí mal.
Sí, lo hace, pero a lo mejor no es conveniente toda la carga extra de la librería para usar la función expand.
En teoría, la VSE después debería integrarse a Bennu, añadiendo variables globales, locales y demás, y cambiando la función de render por un código que lo haga de forma automática (como con el scroll).
Joder, es muy grande este módulo, karma up, estoy deseando probarlo. Por favor, avisad a l1nk3rn3l para que incluya en el Bennupack 1.9 todas estas librerías nuevas, esta en especial me mola un huevo, junto con la svg de DCelso, que todavía no he tenido tiempo de probar :(
esta libreria ya estaba portada en el bennupack
ya esta esta y otras..
porque no me echan una mano con el yeti3d y terminamos el modo8..
;D, otia, que bueno.
Pues habría que tener un listado de módulos bennu por algún lado para que no nos vuelva a pasar :D.
como robaron karmas! que verguenza, nadie mira el bennupack? :P
Joer, vaya noticia me has dado ;)
Splinter, y compañia, obligados a poner la lista obligatoriamente de todos los modulos oficiales y no oficiales conocidos, y tambien de los que se sepa que se estan portando o creando ...
Pongo ya los mios (se excluyen de la lista nuevas versiones de los ya completados) por si alguien se esta repetiendo la tarea:
mod_litha
mod_fire (terminar la beta)
mod_midi (terminar la beta)
mod_open3d (funciones opengl adaptadas al lenguaje div-like, carga de modelos 3ds, con texturas bmp, jpg, png).
ya te digo, después de desperdiciar mis horas en la vse va y ya estaba portada, buaaa, que tontaco que soy, tengo el bennupack instalado y ni me dió por mirar si estaba, dita sea.
Bueno saco de ello más experiencia, de todas formas mi código ha quedado un poquito mejor que el del bennupack, limpié algunas cosas, otras las hice de otra forma, compatibilizé otras cosas con bennu y limpié warnings de compilación.
bien, entonces quizas hay que tomar el tuyo y meterlo en el bennupack... si link lo considera adecuado...
por otro lado, yo solo me encargo de la rama oficial... asi que si quieren Uds. (todos los users) mantener listas publicas y links de dlls, seria grandioso... (creo que es el objetivo de bennupack... pero debo admitir que pocos le dan bola...)
Saca el codigo de una vez hombre, ahora tengo curiosidad de ver tambien el de Expand, ese seguro que esta mejor que el mio ;D
Quote from: DCelso on March 14, 2010, 12:01:24 AM
ya te digo, después de desperdiciar mis horas en la vse va y ya estaba portada, buaaa, que tontaco que soy, tengo el bennupack instalado y ni me dió por mirar si estaba, dita sea.
Bueno saco de ello más experiencia, de todas formas mi código ha quedado un poquito mejor que el del bennupack, limpié algunas cosas, otras las hice de otra forma, compatibilizé otras cosas con bennu y limpié warnings de compilación.
La culpa es de Drumpi, ahora nos toca darle la semana de karmas negativos por listo ;D ;D ;D
Quote from: SplinterGU on March 14, 2010, 12:24:03 AM
bien, entonces quizas hay que tomar el tuyo y meterlo en el bennupack... si link lo considera adecuado...
por otro lado, yo solo me encargo de la rama oficial... asi que si quieren Uds. (todos los users) mantener listas publicas y links de dlls, seria grandioso... (creo que es el objetivo de bennupack... pero debo admitir que pocos le dan bola...)
Debes poner una página con link en la principal que ponga un listado de modulos no oficiales (y su link en cada uno a la página o download del mismo), es así que hacen los autores de demás engines o programas que tienen cosas de terceros. Así que a currartelo ;D
¿Entonces el expand ya estaba en el Bennupack??? Increíble :S
Si que están sí, ahí de una manera un poco warrindonga (sin usar nomenclatura bennu), pero están y van bien. :)
A ver los que van en el bennupack 1.8 son:
hiper3d,voxel (que es vse de ahí quizas la idea de todo de que aún no estaba portada), yeti3d
bennuvideo,sumarlib,showvarlibs,expand,fgfx,fire,ttf,joylibffb,
image,fenix_mng(que aunque se llama así es para bennu :D)
mpeg,
fdsock,libnetwork,net,
bedbx(opendbx), tscroll,sql(sqlite),mod_tinyxml(el único con nomenclatura bennu :D)
water.
Quizas lo que se podría hacer es adaptar estos a la nomenclatura y estandars actuales de bennu :D.
Hala, hoy toca la veda del Drumpi ^^U
¿A mí qué me explicais? yo me descargué el bennupack y veo que es un archivo EXE que ni winrar ni 7zip pueden abrir, así que va directamente al disco de copia de seguridad sin pasar por el doble clic. No quiero que se me ponga a enredar con el sistema, soy muy quisquilloso con eso ;D
Como mucho me sonaba que estaban la fire, la water (que por eso las ponía como ejemplo de "multithread") y creía recordar que ni ETD ni VSE se habían portado (por problemas de compilación, porque no sabían qué era, yo que se, hace dos años y no se volvió a hablar del tema).
Y ahora no me puedo echar atrás: prometí una semana de karmas al portador del VSE y debo cumplirlo. Como poco, añado a link en la lista de karma semanal y san sacabó.
:'( :'( :'(
eeh, yo no quiero karmas regalados :D.
Que alguien me quite los karmas que recibí por portar una mod portada, no quiero karmas que no sean mios :(:(:( :):)
Joooo, pos hala, ya no te doy más :'( Se los doy a Link. Yo que era por el trabajo hecho...
Creo que han sido 3... y otro a windgate :D
querrás decir freeyourmind ¿no?
no importa DCelso... igual te mereces karmas por el esfuerzo y por todo lo que haces...
Los karmas os estan afectando el espirito.... Entonces la fire tambien estaba... Pues entonces ya tengo este Domingo libre hehheh, bueno pues tendré que mirar de una vez el Bennu pack :) Afinal todos tenemos la culpa, ya que tampoco vosotros sabiais lo que ocultaba el bennupack, es así que agradecemos el trabajo de los demás... todos nos merecemos la hoguera sin excepción ;D
Quote from: DCelso on March 14, 2010, 03:36:21 AM
querrás decir freeyourmind ¿no?
Pos si, pos si, ya digo que algo debe estar afectándome a la neurona (aunque lo de confundir nombres no viene de acá ^^U).
A mi me gustaría tener el bennupack en formato descomprimible, porque se que hay muchísimas utilidades interesantes (editores 2D, 3D, animaciones...), tutoriales, ejemplos, librerías... y no lo puedo usar por la tírria que le tengo a los setup.
Por cierto, ya tengo 40 kilos de madera. Un par de carretillas más, unas cerillas y ya podremos ir entrando uno a uno :D
Drumpi, para esos menesteres que comentas yo uso portable virtual box, tengo un windows xp to limpito en virtual box, y una copia de éste guardado en zip. El proceso que hago es instalar en el xp de virtualbox el programa víctima, luego copio en zip la información instalada y la saco del xp virtual al real. Luego cierro virtualbox y sobreescribo la imagen de disco por la guardada en zip y ya tengo otra vez el xp de virtualbox recien limpito. :D.
no solo queria decir ya estaba portado a bennu , no quiero fomentar nada malo
total este es el espiritu que necesita bennu que todos aporten..
¿A quien y a que pregunta respondes, l1nk?
Lo siento no te entendí.
Creo que responde a todo el mundo, diciendo que no es malo que se aporten nuevas compilaciones, que él sólo se limitaba a indicar que ya existía un binario previo, pero que si salen cosas nuevas, mejor :)
Nuevas si, pero sacar cosas repes... ;D
La VSE ya no está repe, ahora es mejor: ya no se cuelga con ciertos ángulos y ya no salen las rayitas multicolor de la muerte :D :D :D
Y es ligeramente más rápida :P
Lo se, si mejoró alguna de las mias tambien dejarán de ser repes :)
Lo que tiene que hacer DCElso, es cuando saque la version oficial la renombre a por ejemplo version 0.9, ya que la otra era la 0.8.
Y cuando saque los fuentes, probaré a ver qué tal va en GP2X, lo mismo lo uso para la portada del Echo, ahora que no tengo restricciones de librerías ni nada :D :D :D
Que por cierto, menuda frikada se me acaba de ocurrir con la VSE, lástima no tener tiempo ^^U
Buenas, llevo peleandome un rato con el expand, y tengo unas cosas que me han desilusionado:
1 - Parece que no funcionan dos llamadas al expand en el mismo loop (cada una a distinta imagen), me pilla sólo el ultimo...
2- No utiliza variable z de profundidad, funciona exactamente como el put_screen, o sea, el primero que se ponga tendrá mayor profundidad z.
3 - Si pongo un mapa por ejemplo con esta funcion, en el mismo loop del expand, o del put_screen (es lo mismo como ya dijé, usar uno o otro, el problema con z es el mismo):
PROCESS por_graph(file, x, y, graph, size, angle, flags, z)
BEGIN
FRAME;
END
la variable z no me sirve de nada, el gráfico va estar siempre por encima del gráfico del expand o del put_screen llame antes o despues el expand/put_screen.
Ayuda please, se puede controlar la z de un put_screen ? Ni que tenga que hacer una nueva version del expand por si se puede, ni que sea internamente...
No he usado la expand, pero ¿no se puede hacer el "render" de dos imágenes sobre mapas distintos? así controlarías la Z con un proceso cada uno. La VSE permite renderizar sobre un mapa (de hecho, se recomienda crear uno) y si haces varios puedes tener varios voxels, rotarlos, agrandarlos, y todo lo que se puede hacer con variables locales.
Es lo que he dicho, el render es sobre 2 imagenes distintas y sólo sale la ultima llamada (en vse tambien tiene el expand, me imagino que tambien fallara).
Pero son 2 problemas distintos, a ver si no los mezclamos :), uno es renderizar 2 imagenes y otra el el tema de las z, para este ultimo olvidate del expand, imagina que estamos hablando de un put_screen, como pondrias una imagen debajo de la que creaste con put_screen ? Es que despues quiero jugar con las propiedades de esa imagen que tenga debajo. O otra pregunta, si hago el put_screen en un proceso aparte y llamo el pintar la imagen que quiero debajo con el proceso 'por_graph' ya se podria controlar la z del put_screen ?
El put_screen es una función que pinta sobre el fondo de pantalla, por lo que debes pintar en el orden correspondiente. Es más, a cada frame deberías hacer un clear_screen o se quedará la imagen anterior.
Quizás te convenga usar mejor la map_put o map_xput sobre el mapa 0 de la librería 0, correspondiente al propio fondo de pantalla, y ahi creo que si puedes asignar Z (y angle, y size, y flags...).
Y creo que la expand no tiene ese problema en VSE, porque creo recordar que en el ejemplo 6 se deforman las 6 caras de un cubo sin problemas.
He compilado este modulo para la Wiz, utilizando codeblocks y el SDK Oficial, configurado para tirar del compilador ARM.
Genero una dll dinamica, y le pongo el nombre 'mod_expand.so', la pongo en la carpeta runtime.
No me esta funcionando, al compilar en la Wiz no me reconoce las funciones del modulo y sale del programa (he visto en el log que es esta la causa). Importar el modulo no da error, sólo da error si llamo funciones suyas.
Alguna sugerencia ?
sin fuentes es dificil...
Sin fuentes !!? Pero no los tienes aqui ? Estoy hablando de la compilación, no he tocado una línea de código, todo el código que usa es portable....
no los veo aqui... pasame el link, por favor, si tu los ves...
a lo que voy es que quizas hay algo mal en la definicion de las funciones, ya he visto en algunos modulos donde cambiaban los parametros (tipos y/o cantidades)... no quiero dar nombres... :D
Aqui tienes, codigo + compilado wiz.
y los makefiles?
No uso makefiles.....
Utilizo la configuración del sdk oficial, eso te genera código valido para la consola (por lo menos ejecutables).
La unica diferencia es que en lugar de elegir console aplication, elijo dynamic library (la extensión so, se la pongo yo, pero he mirado con decimal, y tanto las oficiales como esta, es un ELF, me imagino que tiene que ser valido tambien...).
Te pongo las pantallas de conf.
(http://forum.bennugd.org/index.php?action=dlattach;topic=1227.0;attach=1154)
pense que usabas el toolchains de gcc... pero dudo que te funcione, porque me parece que compilan contra diferentes librerias e incluso pueden tener diferente ABI... la verdad que ahi no te puedo ayudar...
el fuente en C parece estar bien. por lo menos los prototipos.
Buenas, afinal ya tenia los logs en el script, ni me acordaba.
He vuelto a probar.
2 situaciones (el modulo expand se encuentra en la carpeta runtime y el import tiene su nombre):
1 - Compilar en la Wiz:
#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../bgd-runtime
PATH=$PATH:../bgd-runtime
echo 2 > /proc/cpu/alignment
bgdc ExpandDemo.prg 1>stdout1.txt 2>stderror1.txt
bgdi ExpandDemo.dcb 1>stdout3.txt 2>stderror4.txt
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
No genera el dcb, stdout1.txt 2>stderror1.txt vacios
2 - Compilar en el PC, y ejecutado en la Wiz:
#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../bgd-runtime
PATH=$PATH:../bgd-runtime
echo 2 > /proc/cpu/alignment
bgdi ExpandDemo.dcb 1>stdout3.txt 2>stderror4.txt
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
stderror4.txt --> Segmentation fault
(http://www.mundoperros.es/files/u53/perro-abandonado.jpg)
Ningun conocedor del codigo de Bennu me va decir lo que es el 'Segmentation Fault' en los logs ? ::)
en donde viste eso?
Mirate la pagina 3 ::)
en la wiz no importa.
Pero que es lo que no importa.
Joer, me estoy pillando una depresión que no veas :(
en wiz creo que da segment violation cuando sale bennugd, no evita que corra el programa, o aca te esta evitando que corra?
disculpa, pero vengo a 8000km/h.
No funciona.
Pero vamos, si al compilar me dice que no encuentra la funcion, cuando el modulo esta bien en su código y se compila perfectamente...
A mi me huele que se genera como ejecutable aunque le ponga .so en la configuracion, como podria comprobar esto ?
te puedo decir que la .so que subiste junto al fuente, no contiene ni un solo simbolo (ninguna funcion publica), y si es una .so (dll) para wiz.
la verdad que mucho con codeblocks no te puedo ayudar.
es un problema del codeblock.
Buenas, ya he investigado mejor, y realmente se generaba una .so vacia...
Bueno, tengo un problema, hay 3 libs que utilizo al compilar (version windows), para la wiz, hago referencia a las mismas pero del runtime de Wiz.
Pero me dice que el formato esta not recognized... Acaso no son las libs compiladas para wiz que debo importar al compilar algo que use sus funciones para la misma maquina ?
Pongo el log:
Skipping file (no compiler program set): main.c
Linking dynamic library: mod_expand.so
lib\libblit.so: file not recognized: File format not recognized
GNU ld version 2.16.1
Supported emulations:
armelf_linux
armelf
no queres algo de ayuda para hacerlo sin usar el codeblock?
Me imagino que sera sencillo compilarlo por linea de comandos usando makefile, ya que es el mismo compilador.
Si quieres enviarme el makefile y lo pruebo, pero con codeblock tambien es muy sencillo, el problema parece ser las libs.
De todos modos tengo que aprender de una vez a usar makefiles al dedo.
ok, luego armo algo y te lo paso
Grácias. así tendriamos el primer modulo no oficial para wiz pero compilado por Splinter.
Hheheheheheheheheh
no, no, lo compilaras tu, yo no te voy a dar el pescado listo, te voy a enseñar a pescar.
Claro, pero lo digo porque parece anedoctico, yo sólo tengo que darle al play :)
Quote from: FreeYourMind on September 08, 2010, 01:18:47 PM
Claro, pero lo digo porque parece anedoctico, yo sólo tengo que darle al play :)
Eso me recuerda a algo ^^U
nah, solo play no, te dire como se hace 1 vez y luego lo haras tu a partir de ahi... no lo dire otra vez.
Hombre, llevo esperando a que me lo digas todo el dia ;D
dame tiempo... ahora estoy complicado de tiempo...
No te preocupes, mañana.
free, tenes instalado msys? o el SDK tiene make?
me pasas los paths de como tenes el sdk instalado? necesito todas las carpetas.
antes de probar la version que acabo de compilar, vos no estaras probando con el ejemplo que setea el modo de video en 32 bits no? porque te recuerdo que wiz no tiene 32bits de modo de video.
bueno, realmente no tengo tanto tiempo para armar un tutorial, aunque espero que esto te sirva para que lo modifiques y puedas usarlo para cualquier .so para bennugd.
solo tenes que modificar los paths en el Makefile.
saludos.
Muchas grácias. Voy a probarlo y a distribuirlo por los usuarios de la Wiz.
Karmona Up.
(http://vpa-internet.com.ar/blog/wp-content/uploads/2010/05/seo-y-karma.jpg)
de nada, si luego necesitas que te explique algo del makefile, solo pregunta.
saludos.
Ya despierto!!!
Por cierto ya estan pidiendo el de Caanoo.
Asi que si quieres ganarte 2 karmas, vuelves a subir el ejemplo tal cual, pero modificado para Caanoo.
Despues este finde lo intentaré compilar yo, si no me sale ya te cuento, de todos modos me gustaria que fuera un makefile para Windows, pero bueno ya lo modificaré yo :)
por eso te pedi las rutas de tu instalacion windows... bueno, ahora hacelo vos.
Porfa sube el de Caanoo para ver las diferencias. No habra mejor profesor que ese :)
Te prometo que despues, este finde los intentaré compilar yo en Windows.
Ya que será un punto de partida para poder compilar otros modulos para estas consolas.
yo creo que esto mismo se puede hacer internamente en bennugd, por lo menos el dibujar.
Igual con map_block_copy, pero seria mas dificil.
Venga sube el de Caanoo, maestro.
(http://newserrado.com/wp-content/uploads/2008/01/master-splinter-anthony.jpg)
vas a tener que esperar el fin de semana.
ya mismo me tengo que poner a laburar.
(http://forum.bennugd.org/index.php?action=dlattach;topic=1227.0;attach=1471)
A la espera de la version Caanoo, he intentado compilar en Windows, y tengo este problema:
(http://forum.bennugd.org/index.php?action=dlattach;topic=1227.0;attach=1478)
El makefile es este (uso las rutas al compilador del sdk oficial):
BASE_DEV=C:/Programas/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux
PREFIX=$(BASE_DEV)/bin/arm-linux-
BUILD_EXT=.so
PLATFORM=__ARM__
EXTRA_LIBS=
BENNU_CORE=C:/mod_expand/
BENNU_BASE=C:/mod_expand/bennugd
BUILD_APP = mod_expand$(BUILD_EXT)
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
AS := $(PREFIX)as
AR := $(PREFIX)ar
OBJECTS = mod_expand.o
CFLAGS = -DTARGET_LINUX -DTARGET_GP2X_WIZ -O2 -finline-functions -fno-strict-aliasing -Wall -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -D_GNU_SOURCE=1 -D_REENTRANT -I. -I$(BASE_DEV)/include -I$(BENNU_BASE)/core/include -I$(BENNU_BASE)/bgdrtm/include -I$(BENNU_BASE)/modules/libgrbase/ -I$(BENNU_BASE)/modules/libblit/ -I$(BASE_DEV)/include -fPIC
LDFLAGS = -shared -module -avoid-version -L$(BASE_DEV)/lib -L$(BENNU_BASE)/modules/libblit/.libs -lblit -L$(BENNU_BASE)/modules/libgrbase/.libs -lgrbase $(EXTRA_LIBS)
all: $(BUILD_APP)
$(BUILD_APP): $(OBJECTS) Makefile
$(CC) -o $@ $(OBJECTS) $(LDFLAGS)
%.o:%.c Makefile
$(CC) -c $(CFLAGS) $< -o $@
clean:
rm -f $(OBJECTS) $(BUILD_APP)
release: clean all
¿Has metido el código fuente de la mod expand junto con los fuentes de bennu? es que me choca que pongas como BENNU_CORE la dirección de mod_expand? Lo mismo me equivoco yo, también estoy aprendiendo ^^U
En mod_expand esta el codigo c, y dentro una carpeta llamada bennugd la cual dentro tiene otra llamada modules con los modulos del runtime de Bennu para Wiz.
Hay algo mal ?
No se, creo que BENNU_CORE debería apuntar a la carpeta que tiene los fuentes de BGDC, BGDI y libbgdrtm, no a los módulos... creo.
Esperaremos al maestro. Grácias.
muy bien drumpi, deben apuntar a los fuentes (compilados) de bennugd, a las carpetas core y modules.
ademas, el makefile no debe usar espacios, de usar TAB, por lo menos en las lineas que empiezan con espaciado, y esas mismas lineas que tienen espaciado, no debe quitarsele el mismo, debe llevar si o si espaciado con 1 tab
Pero la version Wiz esta todo en la misma carpeta....
He puesto todo bennu en "C:/mod_expand/bennugd/modules",
en el make tengo:
BENNU_CORE=C:/mod_expand/bennugd/modules
BENNU_BASE=C:/mod_expand/bennugd
recordar que el de splinter tenia esto:
BENNU_CORE=/home/splinter
BENNU_BASE=/home/splinter/wizdev/bennugd
Sigo con el mismo problema, help...
perdon, bennu_core me quedo sin darle uso.
en la carpeta que apunta a bennu_base debe estar core y modules, todos sus archivos fuentes y compilados.
Quote from: SplinterGU on September 10, 2010, 05:12:57 PM
vas a tener que esperar el fin de semana.
ya mismo me tengo que poner a laburar.
Por cierto, para que fin de semana era ? ::)
Una pregunta Splinter, en tu ruta '/home/splinter/wizdev/openwiz/toolchain/arm-openwiz-linux-gnu' (base_dev), tienes libs/includes o algo de Bennu, en caso afirmativo, que tienes ?
eso es el path al sdk, no tiene nada que ver con bennu
Splinter, podrias poner el script para Caanoo, falta compilar para ella, y estoy curioso para saber que cambia en el script, mirando las diferencias entre los 2.
Mañana queria volver a intentar en windows compilar el de la Wiz, pero por favor no digas que lo pones sólo cuando lo consiga, que me desespero :)
no entendi.
!!!
Pues hacer lo que habias prometido, has subido la dll compilada para wiz, pues seria subir lo mismo para la caanoo, o sea, el makefile.
yo prometi para la caanoo?
Sólo hay que leer el hilo...
Vamos, que era por saber en que punto cambiabas el makefile para compilar para una u otra.
ah, pero eso es muy simple, te bajas los fuentes de bennugd, miras los scripts de seteo de variables de wiz y de caanoo, y ya sabes como modificar tus makefiles, realmente los makefiles dependen de donde y como tengas instalado los SDK.
los cambios son realmente paths y 1 o 2 seteos bien identificables, no hay mucha ciencia.
PD: el hilo son 7 paginas... :P
Puffff ;D
Acaso no sabes en que página de las 7 pusiste el makefile para Wiz ?
Yo empezaria de esta hacia la primera, y no tendria que leer 7 páginas, eso fijo.
Bueno, ya veo que tengo que estudiarmelo por mi cuenta :)
Grácias.
sinceramente es demasiado simple, y prefiero enseñarte a pescar que darte el pescado, es mas, era lo que te dije cuando te di el makefile de wiz, que era para que aprendas a hacerlo y no depender de otros.
fijate que yo por eso no tengo muchos ports de forma oficial, porque no me gusta ni quiero depender de otros y mucho menos molestarlos para que me armen tal o cual cosa.
ademas, por favor, no te subestimes, yo no te subestimo...
Ya he descubierto todo el tema Splinter, grácias, y grácias a ello incluso descubri el src de otro juego para caanoo :)
El tema es que voy a actualizar el sdk de gph, al ultimo, el cual me imagino tendrá las 2 toolchain (los 2 que usas por separado).
De momento y antes de actualizarlo, quiero compilar el de wiz, he vuelto al tema, pero sigo con el problema 'nothing to be done'
al ejecutar el makefile!!!!
De momento te digo como lo tengo montado a ver si puedes ayudarme a encontrar el error de rutas:
Tengo 2 carpetas:
C:\mod_expand
dentro tengo, mod_expand.c y la carpeta bennugd, que contiene tal cual el src de tu cvs (ultima version).
En la carpeta que llamo el makefile, tengo los binarios del toochain:
C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\bin
aqui es donde llamo tengo y llamo el makefile con 'make makefile'
El makefile es el siguiente:
BASE_DEV=C:/Programas/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux
PREFIX=$(BASE_DEV)/bin/arm-linux-
BUILD_EXT=.so
PLATFORM=__ARM__
EXTRA_LIBS=
BENNU_CORE=C:/mod_expand/
BENNU_BASE=C:/mod_expand/bennugd
BUILD_APP = mod_expand$(BUILD_EXT)
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
AS := $(PREFIX)as
AR := $(PREFIX)ar
OBJECTS = mod_expand.o
CFLAGS = -DTARGET_LINUX -DTARGET_GP2X_WIZ -O2 -finline-functions -fno-strict-aliasing -Wall -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -D_GNU_SOURCE=1 -D_REENTRANT -I. -I$(BASE_DEV)/include -I$(BENNU_BASE)/core/include -I$(BENNU_BASE)/bgdrtm/include -I$(BENNU_BASE)/modules/libgrbase/ -I$(BENNU_BASE)/modules/libblit/ -I$(BASE_DEV)/include -fPIC
LDFLAGS = -shared -module -avoid-version -L$(BASE_DEV)/lib -L$(BENNU_BASE)/modules/libblit/.libs -lblit -L$(BENNU_BASE)/modules/libgrbase/.libs -lgrbase $(EXTRA_LIBS)
all: $(BUILD_APP)
$(BUILD_APP): $(OBJECTS) Makefile
$(CC) -o $@ $(OBJECTS) $(LDFLAGS)
%.o:%.c Makefile
$(CC) -c $(CFLAGS) $< -o $@
clean:
rm -f $(OBJECTS) $(BUILD_APP)
release: clean all
Es todo, a ver si puedes ayudarme con esto.
no, solo tienes que hacer make, no pongas la palabra makefile, ya que con eso estaras intentando hacer un objeto que se llame makefile, pero no existe ningun objeto con ese nombre dentro del makefile
perdon, que tonto soy, el error es haciendo make, y es el siguiente:
no rule to make target 'mod_expand.o' needed by 'mod_expand.o'. stop.
En su dia lo mire por internet y podria ser algun espacio en las rutas, pero no creo, ya que lo edito con notepad++ y no con editor windows.
la de los makefiles es:
objeto: dependencias
<tab>comando
siempre hay que usar <tab>, pero me suena que no es tu caso.
He estado poniendo tabs, pero nada, cambie algo el script y ahora tengo el error '*** multiple target patterns' en la linea 23, donde pongo a pelo mod_expand.so
La verdad, estoy desesperado, es una mierda en el script y no doy con la solución :(
BASE_DEV=C:/Programas/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux
PREFIX=$(BASE_DEV)/bin/arm-linux-
BUILD_EXT=.so
PLATFORM=__ARM__
EXTRA_LIBS=
BENNU_CORE=C:/mod_expand/
BENNU_BASE=C:/mod_expand/bennugd
BUILD_APP=mod_expand.so
CC:=$(PREFIX)gcc
LD:=$(PREFIX)gcc
AS:=$(PREFIX)as
AR:=$(PREFIX)ar
OBJECTS=mod_expand.o
CFLAGS=-DTARGET_LINUX -DTARGET_GP2X_WIZ -O2 -finline-functions -fno-strict-aliasing -Wall -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -D_GNU_SOURCE=1 -D_REENTRANT -I. -I$(BASE_DEV)/include -I$(BENNU_BASE)/core/include -I$(BENNU_BASE)/bgdrtm/include -I$(BENNU_BASE)/modules/libgrbase/ -I$(BENNU_BASE)/modules/libblit/ -I$(BASE_DEV)/include -fPIC
LDFLAGS=-shared -module -avoid -version -L$(BASE_DEV)/lib -L$(BENNU_BASE)/modules/libblit/.libs -lblit -L $(BENNU_BASE)/modules/libgrbase/.libs -lgrbase $(EXTRA_LIBS)
all:$(BUILD_APP)
$(BUILD_APP):mod_expand.so Makefile
$(CC) -o $@ mod_expand.so $(LDFLAGS)
%.o:%.c Makefile
$(CC) -c $(CFLAGS) $< -o $@
clean:
rm -f $(OBJECTS) $(BUILD_APP)
release:clean all
aca
$(BUILD_APP):mod_expand.so Makefile
$(CC) -o $@ mod_expand.so $(LDFLAGS)
en $(CC) va un tab delante y quitar el mod_expand.so... puf, ahi va mod_expand.o
.....
puff.... pero no habia hecho yo uno para wiz? por que agregaste cosas? lo unico que tenias que tocar eran las variables de arriba, nada mas que eso.
al makefile de wiz tenes que cambiar...
BASE_DEV=/home/splinter/wizdev/openwiz/toolchain/arm-openwiz-linux-gnu
PREFIX=$(BASE_DEV)/bin/arm-openwiz-linux-gnu-
BENNU_CORE=/home/splinter
BENNU_BASE=/home/splinter/wizdev/bennugd
CFLAGS = -DTARGET_LINUX -DTARGET_GP2X_WIZ -O2 -finline-functions -fno-strict-aliasing -Wall -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -D_GNU_SOURCE=1 -D_REENTRANT -I. -I$(BASE_DEV)/include -I$(BENNU_BASE)/core/include -I$(BENNU_BASE)/bgdrtm/include -I$(BENNU_BASE)/modules/libgrbase/ -I$(BENNU_BASE)/modules/libblit/ -I$(BASE_DEV)/include -fPIC
por los valores correctos, nada mas que eso.
en el caso de CFLAGS cambia esto
-finline-functions -fno-strict-aliasing -Wall -ffast-math -fomit-frame-pointer -mcpu=arm920t
no recuerdo que va, pero fijate en el script de seteo de variables de caanoo que viene con los fuentes de bennugd.
Recuerda que estoy compilando para wiz no caanoo.
Por cierto la he vuelto a compilar de nuevo con codeblocks por probar, se queda en 2.67 kb en lugar de 4,85 kb de la tuya, y no va en la wiz (esto ya lo comente antes de probar con el makefile).
Volveré al makefile, tengo que conseguir compilarla de esta forma...
Una cosa, me estoy fijando, en el open2xwiz, tienes el CFLAGS con comillas, pero en el makefile que pusiste no tiene.
Estas seguro que el makefile que pusiste con la so compilada te funciona ? Fue el que usaste, o cambiaste algo a ojo ?
vamos por partes...
1) el make que puse y subi aca es para wiz, no tenes que tocar nada, salvo los paths
2) en codeblock es mas chico porque le saca los simbolos de debug, para eso tenes que hacerle strip al .so resultado
3) en los makefiles no van entre comillas
4) funciona perfecto, fue el que use
5) te debe faltar alguna libreria, captura los logs de compilacion del bgdc cuando lo corras en la wiz, otra opcion puede ser que estes apuntando a otro sdk
por favor, avisa si lo lograste
Sobre el makefile voy a intentarlo de nuevo.
Sobre el codeblocks, este compila, aunque salen algunos detalles de .so no encontradas, te paso el log completo, mira en las rutas del toolchain a ver si algo de esos errores es lo que hace que al final quede inservible.
-------------- Clean: target in WizTest ---------------
Cleaned "WizTest - target"
-------------- Build: target in WizTest ---------------
Skipping file (no compiler program set): main.c
Linking dynamic library: mod_expand.so
GNU ld version 2.16.1
Supported emulations:
armelf_linux
armelf
using internal linker script:
==================================================
/* Script for --shared -z combreloc: shared library, combine & sort relocs */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
"elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0; */
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0 + SIZEOF_HEADERS;
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn :
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data.rel.ro*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
KEEP (*(.text.*personality*))
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
*(.glue_7t) *(.glue_7)
} =0
.fini :
{
KEEP (*(.fini))
} =0
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (0x8000) - ((0x8000 - .) & (0x8000 - 1)); . = DATA_SEGMENT_ALIGN (0x8000, 0x1000);
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
/* Ensure the __preinit_array_start label is properly aligned. We
could instead move the label definition inside the section, but
the linker would then create the section even if it turns out to
be empty, which isn't pretty. */
. = ALIGN(32 / 8);
.preinit_array : { KEEP (*(.preinit_array)) }
.init_array : { KEEP (*(.init_array)) }
.fini_array : { KEEP (*(.fini_array)) }
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin*.o(.ctors))
/* We don't want to include the .ctor section from
from the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
KEEP (*crtbegin*.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.data.rel.ro : { *(.data.rel.ro.local) *(.data.rel.ro*) }
.dynamic : { *(.dynamic) }
. = DATA_SEGMENT_RELRO_END (0, .);
.got : { *(.got.plt) *(.got) }
.data :
{
__data_start = . ;
*(.data .data.* .gnu.linkonce.d.*)
KEEP (*(.gnu.linkonce.d.*personality*))
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .;
PROVIDE (edata = .);
__bss_start = .;
__bss_start__ = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections. */
. = ALIGN(32 / 8);
}
. = ALIGN(32 / 8);
_end = .;
_bss_end__ = . ; __bss_end__ = . ; __end__ = . ;
PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
.note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }
/DISCARD/ : { *(.note.GNU-stack) }
}
==================================================
attempt to open /cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/lib/crti.o succeeded
/cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/lib/crti.o
attempt to open /cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/crtbeginS.o succeeded
/cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/crtbeginS.o
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libstdc++.so succeeded
-lstdc++ (C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libstdc++.so)
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libm.so succeeded
-lm (C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libm.so)
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libgcc_s.so succeeded
-lgcc_s (C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libgcc_s.so)
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc.so succeeded
opened script file C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc.so
opened script file C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc.so
attempt to open libc.so.6 failed
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc.so.6 succeeded
libc.so.6 (C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc.so.6)
attempt to open libc_nonshared.a failed
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libc_nonshared.a succeeded
attempt to open C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libgcc_s.so succeeded
-lgcc_s (C:\Program Files\GPH_SDK\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\arm-linux\lib/libgcc_s.so)
attempt to open /cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/crtendS.o succeeded
/cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/crtendS.o
attempt to open /cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/lib/crtn.o succeeded
/cygdrive/c/Program Files/GPH_SDK/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/lib/crtn.o
Output size is 2,68 KB
Process terminated with status 0 (0 minutes, 19 seconds)
0 errors, 0 warnings
en mi vida vi eso, el codeblocks es siniestro.
Bueno ya me instale el de Caanoo, ahora mismo estoy instalando el cygwin (cosa no necesaria para el de Wiz, ya que tenia la cygwin1.dll y dependencias en la carpeta bin del toochain, y funcionaba de esta forma).
Voy a probar con codeblocks compilarlo para caanoo a ver si chuta, si lo hace, dejo ya de perder el tiempo ;)
cygwin no, te sugiero usar mingw y msys
Si me lo pide el arm-gph-linux-gnueabi-c++.exe, como no voy a tener que utilizarlo !? El mingw es sólo para host, para target es el que te he dicho :)
De todos modos aunque el path (variable de sistema) del cygwin tampoco me funciona!!! Ya he copiado 2 o 3 dll's de cygwin y ya no tengo problemas con el.
Ahora tengo otros problemas con el SDK de Caanoo, me he tirado un par de horas y ya estoy harto, desde no localizarme el 'crti.o' que puse en la carpeta del src y funciono (sólo en uno de mis proyectos, cosa rara que se diga...), pero tengo otro problema, no me encuentra la 'libc.so.6', por mas que la tenga su ruta y la ponga en todo puto sitio...
Por hoy lo dejó, tanta configuración me pone enfermo...
El codeblocks tambien se pone raro a veces el maldito...
solo necesitarias copiar el runtime de cygwin para el compilador, y con eso deberia ir, las librerias que usa para generar los ejecutables no son de cygwin, son del SDK...
me suena a que tienes un quilombo de cosas, que has metido mano por todos lados y cargado un par de cosas.
tambien hay archivos con extension .la donde tienen las rutas de las librerias reales, y eso es en momento de instalacion, los paquetes que he probado yo del SDK de GPH los tuve que tocar a mano, porque GPH empaqueto el SDK que tienen instalado, y por ende con los paths que ellos tienen instalados, y no funcionan en otros sistemas, por eso lo ideal en vez de subir los SDK armados, deberian subir los paquetes del toolchains para que se genere en la pc donde se va a usar, voy a revisar esto y a hablar con Simon al respecto si aun sigue siendo asi en las ultimas versiones.
efectivamente es como dije, los paths dentro de los .la estan seteados a la configuracion que tiene el entorno de desarrollo de GPH, y no a donde el instalador instala las cosas.
creo que te va a ser dificil hacer funcionar las cosas.
Vaya, pero he visto a mas instalandolo y no tenian problemas. Es que somos muy pocos en realidad tocando los sdk, y en windows bastante menos, heheheheh
Mañana lo miro.
no se, a mi me dio problemas haciendo uso de las librerias e instalando paquetes como la sdl_mixer, pero se ve que para algunas cosas funciona, no lo se...
Me he pasado a linux para intentar compilarlo, lo estoy haciendo para Caanoo.
No he tenido problemas para instalarme las cosas o de rutas, en linux estas cosas van mucho mejor :)
Solo tengo un problema en el paso final, ya he generado el objeto mod_expand.o, el problema es al hacer merge de libgrbase.so.
Utilizo los sources de la version r184 pero las so compiladas son de una version anterior (libblit.so y libgrbase.so), creo que el problema viene de esto, porque la so que utilizo son version EABI 0 y el target es version EABI 4, y no dispongo de las ultimas compiladas ni estoy por compilar Bennu, si puedes sube la ultima version compilada para caanoo, con el correcto EABI, o pasame solo estos 2 modulos.
Otra cosa, he tenido que copiar ambas so a la carpeta lib del toochain, no me las localizaba.
El error es el siguiente:
/home/geca/Geca/mod_expand/caanoo_toolchain/gcc-4.2.4-glibc-2.7-eabi/bin/../lib/gcc/arm-gph-linux-gnueabi/4.2.4/../../../../arm-gph-linux-gnueabi/bin/ld: ERROR: Source object /home/geca/Geca/mod_expand/caanoo_toolchain/gcc-4.2.4-glibc-2.7-eabi/lib/libgrbase.so has EABI version 0, but target mod_expand.so has EABI version 4
/home/geca/Geca/mod_expand/caanoo_toolchain/gcc-4.2.4-glibc-2.7-eabi/bin/../lib/gcc/arm-gph-linux-gnueabi/4.2.4/../../../../arm-gph-linux-gnueabi/bin/ld: failed to merge target specific data of file /home/geca/Geca/mod_expand/caanoo_toolchain/gcc-4.2.4-glibc-2.7-eabi/lib/libgrbase.so
collect2: ld returned 1 exit status
make: *** [mod_expand.so] Error 1
Gracias
Hay algo por internet, pero ya veo que me las tendré que apañar solito :-[
Question:
When trying to build U-Boot with an EABI compliant tool chain, I get such error messages:
arm-ld: ERROR: Source object ... has EABI version 4, but target ... has EABI version 0
What does that mean, and how can I fix that?
Answer:
"EABI version 0" means the "apcs-gnu" ABI, while "EABI version 4" is the "aapcs-linux" ABI, aka "gnueabi".
All U-Boot ARM sources are built with "-mapcs-gnu" option set in "cpu/arm/config.mk", while libgcc.a modules are built in "gnueabi" format, which is for example the ARM GCC default in ELDK Release 4.2.
So the real problem is compatibility between toolchain ABI and U-Boot ARM ABI. In the Linux kernel there is a special kernel config option for EABI-enabled tool chains (CONFIG_AEABI), which enables special pieces of code in ARM assembler modules. We could follow this approach, reworking existing assembler sources and respective config.mk files in U-Boot.
Alternatively, the tool chain could provide a separate version of libgcc.a built with old ABI. This could be done using the multilib approach. The advantage here is that no U-boot changes will be required.
Estoy totalmente en bajo, nadie me ayuda con esto...
Ni que sea saber donde obtener el toolchain para Caanoo, que tenga version 0 (la utilizada en la compilacion de Bennu) en lugar de la version 4, que es la version del toolchain oficial de GPH...
Splinter dame tu toolchain utilizado en tu compilacion o dime donde corojones lo has obtenido por diosssss :( :(
mi toolchains es de linux, y la baje de gp2xspain.
Que link en concreto ?
La mia tambien es, logicamente la de Windows no te funcionaria en Linux xDDDD
mira lo que me preguntas... fijate el primer toolchain que salio.
sino tambien podes compilar tu propia version con tu toolchains
Es que no se cual es el link del primero porque en cada esquina sale uno, hay muchos hilos y te pierdes...
He probado 2 distintas y ambas eran la 4, no puedes enviarme el tuyo en algun link para descarga ?
De todos modos, deberias pasarte a la ultima :)
Me acaba de decir hardyx en Gp32spain, que la version 0, es en realidad el de Wiz (old eabi --> oeabi), y la de caanoo es la version 4, eabi.
No se como lo habras hecho, pero tiene pinta de que tus libs de Bennu sean compiladas con el toolchain de wiz y esten funcionando en caanoo...
Raro esto, a ver si salimos de dudas. De momento estoy comprobando que no me haya equivocado de libs, y haya puesto las de wiz, pero apuesto que no...
NO ME LO PUEDO CREER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
Estaba usando las libs de wiz y juraria que no!!!!
Ya tengo el port, yuhuhuhuhuhuhuhhuhuhuhu, que contento estoy, es el principio de un largo camino heheheheheheh.
Descarga: Quitad la extension rar :)
http://dl.openhandhelds.org/cgi-bin/caanoo.cgi?0,0,0,0,19,587 (http://dl.openhandhelds.org/cgi-bin/caanoo.cgi?0,0,0,0,19,587)
puf! al final te habias confundido... jua!!!!
karma!
Bueno, por lo menos tambien has aprendido que el eabi version 4 es el de caanoo y el 0 el oeabi de Wiz ;D
jajaja!