问题
I have compiled armv7 static libraries (lib*.a) and i'm going to compile iPad Air app (arm64). I'm getting linker warning and then linker error:
$ lipo -info /Users/user/Documents/dev/src/iOS_Projects/iProject/libMyLib.a
input file /Users/user/Documents/dev/src/iOS_Projects/iProject/libMyLib.a is not a fat file
Non-fat file: /Users/user/Documents/dev/src/iOS_Projects/iProject/libMyLib.a is architecture: armv7
Ld: warning: ignoring file /Users/user/Documents/dev/src/iOS_Projects/iProject/libMyLib.a, file was built for archive which is not the architecture being linked (arm64): /Users/user/Documents/dev/src/iOS_Projects/iProject/libMyLib.a ignoring file
It's undesirable (and can be impossible) to recompile static libs for arm64. How can i use them?
回答1:
With difficulty.
You can only switch between AArch32 state and AArch64 state at an exception boundary, so whilst e.g. 64-bit kernel/32-bit userspace is possible, it's impossible to use both in a single process. Since it's an entirely different instruction set/register layout/exception model/etc. there's no 32/64-bit interworking in the style of ARM/Thumb (which are essentially just different encodings of the same instructions).
In general (I'm not familiar with iOS specifics, but I assume it supports "legacy" AArch32 processes as Linux does):
- If the libraries are completely integral to your code, your best bet is to simply give in and compile your app as 32-bit.
- If you have super-crucial-absolutely-must-be-64-bit code but the library calls are not in the fast path, you could compile them into a 32-bit helper program that you spawn as an additional process and call via some form of IPC.
- Otherwise you're looking at the ridiculously impractical prospect of some form of binary translation.
I gather that iOS offers no support for IPC, which rather rules out the second option in this particular case.
来源：https://stackoverflow.com/questions/25249832/how-to-link-ipad-air-app-arm64-against-existing-armv7-static-libraries