The statically linked SDL was compiled without qtopia.
That is why I am trying to build libqte and libqpe with soft-float.
I think I got libqte built right but libqpe is problematic.
How do you fix the fact that it is upside down?
You are getting only 12.5 fps. Are you running at a higher resolution?
I dont know anything about readelf or uclibc.
In the future, I might build a toolchain based on xscale. It will be with gcc 3.4.X. Maybe we canget higher frame rates with xscale optimization.
But right now, libqpe first.
If you check out the zport SDL cvs you can find code that gets the rotation right for various different models.
My command line is set to 320x240, however, because I'm running from the console the frame buffer is probably set to 640x480 causing quake to run quad pixel blocks so that may account for the drop in frame rate. When running under Qtopia I can tell Qtopia to scale to 320x240, may make up the frame rate by doing that.
I found the cause of the math.h/libm proble .. take this sample...
mathtest.h....
#include <stdio.h>
#include <math.h>
float module1();
float module2();
module1.c...
float module1()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floot(f1);
return f2;
}
module2.c.....
#include "mathtest.h"
float module2()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floor(f1);
return f2;
}
test.c....
#include "mathtest.h"
main()
{
printf("%f\n",module1());
printf("%f\n",module2());
}
...now first compile with...
arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c -msoft-float
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm
(I made a static link version of libfloat).
Results when you run test on the Z...
0
0
Now recompile as follows...
arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm
And results are...
2
2
Excellent it works, now why
?
I'm pretty sure now that if you link the main() module in your executable as soft-float it removes the exception handler that normally sits on SIGFPE which is what is normally used to handle the unimplemented FP opcodes. Since the libm library is linked with hard floating point this is why the library is failing.
Now, unfortunately, libSDL throws a spanner in the works. You start up with SDL_main rather than main() and I have tried SDL build with both FPE and soft-float... both barf.
So I now need to find out why SDL is linking with FPE unhooked from the SIGFPE handler.
Anyway, I'm a much happier bunny now I now the cause of the problem !
