ARM FP compilation

I've been trying to compile a program that uses a library built with hardware floating-point.
It tells me that I've compiled the main program with software FP, but on each module that comprises it (as well as the program itself) I have explicitly said "use hardware FP please" (-mhard-float, see http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html). If you want, here is the compiler output (non-important stuff truncated for readability):

arm-gcc -Wall -Wextra -mhard-float -I. -I/opt/arm/include -c main.c -o main.o
arm-gcc -Wall -Wextra -mhard-float -I. -I/opt/arm/include -c touchscreen.c -o touchscreen.o
arm-gcc -Wall -Wextra -mhard-float -I. -I/opt/arm/include -c buttons.c -o buttons.o
arm-gcc -L. -L/opt/arm/lib -lts -mhard-float main.o touchscreen.o buttons.o -o touchscreen-test
/opt/arm/bin/arm-ld: ERROR: /opt/arm/lib/libts.so uses hardware FP, whereas touchscreen-test uses software FP
/opt/arm/bin/arm-ld: failed to merge target specific data of file /opt/arm/lib/libts.so
/opt/arm/bin/arm-ld: ERROR: main.o uses hardware FP, whereas touchscreen-test uses software FP
/opt/arm/bin/arm-ld: failed to merge target specific data of file main.o
/opt/arm/bin/arm-ld: ERROR: touchscreen.o uses hardware FP, whereas touchscreen-test uses software FP
/opt/arm/bin/arm-ld: failed to merge target specific data of file touchscreen.o
/opt/arm/bin/arm-ld: ERROR: buttons.o uses hardware FP, whereas touchscreen-test uses software FP
/opt/arm/bin/arm-ld: failed to merge target specific data of file buttons.o
collect2: ld returned 1 exit status
make: *** [touchscreen-test] Error 1

Where am I supposed to tell it to make touchscreen-test with hardware FP? It seems to ignore when I tell it to, even though I read somewhere that hardware is the default.

-mfpu=name?

why aren't you using -march/-mcpu and -mtune?

I've tried specifying -mcpu and -mtune (arm9), but it still spits out those errors.
I don't know about -mfpu because there is very little documentation on this machine, but various forums tend to agree that there is no hardware FPU anyway. Which is odd, because this libts is in the official firmware.

I guess I'll find some other software that uses the touch screen and see how they did it.

Write a dummy program that uses floats and compile it to assembler. See if it uses hard or soft float.

>>5
compile it to assembler
Your abuse of the English language makes me weep for humanity.

>>6
When you invoke GCC, it normally does preprocessing, compilation, assembly and linking.
...
-S  Stop after the stage of compilation proper; do not assemble.  The output is in the form of an assembler code file for each non-assembler input file specified.
-- man(1) gcc

What was that about his English?

>>7
The fact that the gcc man page gets it wrong as well doesn't make it right. Though arguably ``assembler code file'' is less wrong than plain ``assembler''.

>>1
What device are you compiling for? I know your compiler troubles are unrelated but... are you sure it has an FPU? If that's a phone it probably doesn't. If it's a DS it certainly doesn't.

PS. if you're using an ARM9E series you can target it with Go. (Not that you'd want to.)

>>8
Or maybe you got it wrong. I'm going with that one.

>>7
„assembler ... file‟ ≠ „assembler‟

>>10
Decades of use and plain common sense disagree with you, sport. Referring to any assembly language as ``assembler'' makes as much sense as referring to C as ``compiler'' or FIOC as ``interpreter''.

>>12
Why am I being trolled?

>>13
because you're french.

>>13
Yes, it's easier to just paint people you disagree with as trolls than it is to admit you're wrong, isn't it?

Update
Instead of fighting with the hard-float library, I found the source and let gcc handle the float-abi itself. It compiles, but I haven't tried running it yet.
No matter what I told it to do, it always compiled using hard-float but linked the final executable using soft-float (even when using the same flags for both). I have no idea why.


>>9 It's the GP2X Wiz, half-sibling to the Pandora console that /g/ masturbated over before it came out. I'm pretty sure it has no FPU, but using hard-float means that it will try to use hardware, and if that isn't there just use software instead, so there's no real reason to specify software FP.

>>16
It works. Huzzah!

>>15
I'm not sure, I haven't tried. I only call troll when obviously false baseless assertions are made.

>>18
There's nothing baseless about basic grammar.

OP, is this for an Android project? I heard Android apps always compile with soft floats because some of the earlier devices don't have FPUs, but apparently they're doing something different with floating point support in Froyo. Is this true?

>>20
As said in >>16 this is for the GP2X.

(where did >>21 go?)