0
0

I’m having trouble building armv6/armv7 fat binaries for the iPhone. The armv6 part works fine, but none of the FMOD symbols are found by the linker when building for armv7. I ran otool against the library and got this curious result:

$ otool -f libfmodex_iphoneos.a
Fat headers
fat_magic 0xcafebabe
nfat_arch 2
architecture 0
cputype 12
cpusubtype 6
capabilities 0x0
offset 48
size 1783144
align 2^2 (4)
architecture 1
cputype 12
cpusubtype 0
capabilities 0x0
offset 1783192
size 1982432
align 2^2 (4)
Archive : libfmodex_iphoneos.a (architecture armv6)
Archive : libfmodex_iphoneos.a (architecture arm)

So yes, I can see why architecture armv7 isn’t linking, but how is this supposed to work?

I am using XCode 3.2.1 and compiling against the iPhone SDK 3.0 with a deployment target of OS 2.2.1.

  • You must to post comments
0
0

What linker errors are you getting? Do you have this same problem with the examples?

I have looked into the subtype missing from the armv7 slice and found a fix. Currently we compile using GCC 4.0 to keep compatibility with OS 2.2.1 but it seems this causes armv7 to miss it’s subtype. I have changed it so FMOD will build armv6 with GCC 4.0 and armv7 with GCC 4.2. This fixes the discrepancy you noticed.

  • You must to post comments
0
0

My link errors were undefined symbols for all of FMOD::* that I was using.

I could not not reproduce the problem with the the playsound example. But the effort to reproduce it did lead me to a useable workaround. The key difference between the example and my application is that the example links to libfmod directly, whereas my app links to our internal framework library, which in turn was linked with libfmod. This worked fine for armv6, but apparently not with the armv7/arm funny business. So I can fix my immediate problem by changing how I link.

I will also update my fmod and try my old method again with your armv7 fix.

Thanks!

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.