Question

According to the literature, an A6 processor will execute ARMv7 code. My project is failing at link because a library was built for ARMv7, but the application is built for ARMv7s.

A typical message is (when I attach my iPad 4 (Retina) or iPhone 5):

ld: warning: ignoring file /usr/local/ssl/iphoneos/lib//fipscanister.o, file was built for armv7 which is not the architecture being linked (armv7s): /usr/local/ssl/iphoneos/lib//fipscanister.o
ld: warning: ignoring file /usr/local/ssl/iphoneos/lib//libcrypto.a, file was built for archive which is not the architecture being linked (armv7s): /usr/local/ssl/iphoneos/lib//libcrypto.a

Undefined symbols for architecture armv7s:
  "_FIPS_incore_fingerprint", referenced from:
      _FINGERPRINT_premain in fips_premain.o
  "_FIPS_signature", referenced from:
      _FINGERPRINT_premain in fips_premain.o
  "_FIPS_text_start", referenced from:
      _FINGERPRINT_premain in fips_premain.o
ld: symbol(s) not found for architecture armv7s

I know I can resolve this by removing ARMv7s from Valid Architectures (VALID_ARCHS), but I’m not sure why since the A6 processor can execute A5 object code. Or I can perform an additional build of the library for the ARMv7s architecture, but that’s more work and requires a different on-disk directory structure.

Is there any magic to link an ARMv7 library with an ARMv7s application?

Answer 1

From Jim Grosbach on the Xcode mailing list, the linker switch -allow_sub_type_mismatches should allow ld to proceed with linking. And from Apple’s ld man pages:

 -allow_sub_type_mismatches
             Normally the linker considers different cpu-subtype for ARM
             (e.g. armv4t and armv6) to be different different architec-
             tures that cannot be mixed at build time.  This option
             relaxes that requirement, allowing you to mix object files
             compiled for different ARM subtypes.

There’s also a Changelog entry that details the environmental variable called LD_ALLOW_CPU_SUBTYPE_MISMATCHES.

However, I found -allow_sub_type_mismatches simply did not work on Xcode 4.5.2. Grepping the web reveals a few Apple RADAR’s for -allow_sub_type_mismatches. See, for example, radar://6134468.

Hopefully its fixed by now, but nothing surprises me when it comes to Apple and their defective software.