iOS: error when running project on real device - c++

I included an external C++ library for my iOS project. This library was compiled and linked with my project from this: http://github.com/chili-epfl/chilitags/
Then when I run the project on simulator, it compiles. But when I run the project on real device like iPhone7, it fails.
The error was clear:
warning: ignoring file /usr/local/lib/libchilitags.dylib, file was built for x86_64 which is not the architecture being linked (arm64): /usr/local/lib/libchilitags.dylib
Because the lib file was ignored, the functions I used all caused fatal link error.
The reason was clear but I don't know what to do. iPhone7 was arm64 architecture but the file was x86_64 architecture and we have to run it on real devices.
So, what should I do so that I can run x86_64 libs on arm64 real devices? Thanks in advance.

BSo, what should I do so that I can run x86_64 libs on arm64 real devices?
The problem is in different processor instruction set used in x86 and arm64.
So, you should compile the library for arm64 or find it already compiled for target architecture.

Related

Building for iOS, but linking in object file built for macOS

I'm working on a program that needs to be linked to libtorch_lite, and Essentia, on iOS, and have had Essentia working on iOS for a while, but when trying to add the torch dependency, which requires the -all_load linker flag to work at runtime, and I got this error:
ld: in
/Users/sylmorrison/JUCE_old/UserModules/kalide_extractors_juce/libs/iOS/arm64/libessentia.a(nnls.c.1.o),
building for iOS, but linking in object file built for macOS, file
'/Users/sylmorrison/JUCE_old/UserModules/kalide_extractors_juce/libs/iOS/arm64/libessentia.a'
A lipo -info on libessentia.a returns arm64 and arm7, and if I leave out the -all_load flag everything works fine, but torch errors at runtime (undefined reference to aten::unsqueeze)
Because torch has a load of extra dependencies, and because I thought I just needed the -all_load flag somewhere, I thought I'd try compiling it into a static library, and then linking to that library, but doing that results in the same error. I also tried modifying Essentia's build script to add an all_load flag (out of desperation mostly), which didn't get me anywhere. Any suggestions would be amazing, am at a loss about what's going on, it's like Xcode, when the all_load flag is enabled, convinces itself it's a macOS static library. If it makes a difference, I'm using an M1 Mac mini on Monterey
Okay, fixed it by figuring out which files essentia wanted to compile when cross compiling for iOS, copying them and the headers to a new folder, and then making an Xcode project to build an iOS static library, I guess due to the cross compiling somehow some of the object files were actually for macOS?

ld: Invalid record for architecture arm64

I'm building a framework for tvOS and use an obfuscation software. All sources are compiled with -emit-llvm, obfuscator processes LLVM IR code, then it is compiled into .o with clang++, then ld is being called to produce the final binary and ld fails with this error:
ld: Invalid record for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Program xcrun returned error code 1
Reproducible on different machines with Xcode 11.2.1 and 11.3.
How can I troubleshoot this error? I've added -v to the linker flags but it did not add any hints to the output.
In my case, I was getting this error when the app was linked to external libraries but only when generating the Product Archive.
The solution for me was to disable the bitcode of the Target under Build Settings > Build Options.
I had it previously disabled but my Xcode updated recently and the setting might have gotten overridden.
Answering my own question once again, just in case someone else will hit this issue.
In my case the problem was caused by one of the libraries I was linking to, that was built for arm64e for tvOS. It was a fat binary with arm64, arm64e and x86_64 slices. For some reason ld didn't like it (even though I was building the framework only for arm64) and was throwing out this error. Removing arm64e slice fixed the issue.
Another interesting detail is that Debug build linked fine with that library.

Linking error iLBC codec library from webRTC to iOS app

I've been trying to include libilbc.a library from the webRTC project into my iOS app. I'm linking it to static library (c++, Xcode project) and then linking this library to my iOS app. It's all in one workspace.
I'm stuck on the next linking error:
Undefined symbols for architecture arm64:
"_WebRtcIlbcfix_EncoderInit", referenced from:
If I check the library architecture I get the right info:
$ lipo -info libilc.a
$ Non-fat file: libilbc.a is architecture: arm64
Also if I check the content of the library, it includes the object:
$ nm libilbc.a | grep "_WebRtcIlbcfix_EncoderInit"
$ U _WebRtcIlbcfix_EncoderInit
I have included header files into the Xcode project and linked with -lilbc flag.
Remark:
I have successfully build the same project for simulator with different library that I got on Github and it worked (meaning, there is nothing wrong with the linking or including header files). The problem is that mentioned library isn't compiled for arm64 architecture.
I would really appreciate if someone knows where could I get compiled ilbc library (for ios arm64) or how to integrate the library from the webRTC project.

Undefined symbols for architecture arm64: "cv::String::deallocate()"

When I add a ".a" file which includes opencv.framework,Xcode encountered such compile errors:
I am pretty sure opencv.framework is there,and I am using opencv 3.1,it should already support arm64. But why does it keep complaining about this? How can I fix it? Thanks a lot.
lipo - info shows following information:
Architectures in the fat file: /Users/Fumin/libVisageWrapper.a are: armv7 i386 x86_64 arm64
You should verify that the library is correctly supporting arm64 using this command:
lipo -info libYourLib.a
The output of this command should show this:
Architectures in the fat file: libYourLib.a are: armv7 arm64
A fat file means a file which holds binary elements for possibly more than one architecture.
If arm64 is missing, you can't build a target for arm64 devices. You might need to ask your supplier of the library to build a fat version which includes the arm64 architecture.
It turns out there is already an opencv library in some other library,so two instance opencvs are conflictting with each other. After .a file provider provide a new version using the same opencv library, now it works fine.

Non-sense error Undefined symbols for architecture armv7

I've built a 32 bit library that is a requirement to my project. Here's its lipo info:
LP:lib hcabral$ lipo -info Release-iphoneos/librmservices_iphone.a
input file Release-iphoneos/librmservices_iphone.a is not a fat file
Non-fat file: Release-iphoneos/librmservices_iphone.a is architecture: armv7
I link the library in my project, it shows up in "Link Binary with binaries", etc., and yet I get this error:
Undefined symbols for architecture armv7:
"std::_List_node_base::hook(std::_List_node_base*)", referenced from:
xpath::YaccParser::getObjectPointer(uft::Value*&, bool) in librmservices_iphone.a(xpath_yacc.o)
xpath::YaccParser::performLexicalAnalysis(uft::Value*&) in librmservices_iphone.a(xpath_yacc.o)
"std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)", referenced from:
xpath::Context::removeDynamicContext(uft::Value const&) in librmservices_iphone.a(xpath_context.o)
"_kCFProxyPasswordKey", referenced from:
DLProxySettingsController::getSystemProxySettings() in librmservices_iphone.a(DLProxySettingsController.o)
"_kCFNetworkProxiesHTTPProxy", referenced from:
(...)
All the projects I limited to armv7 and no solution. Any ideas?
So, I have a project A that is pure Objective-C, but it depends on a Project B that is C/C++ and Objective-C, and happens to be 32-bit code only.
Up until Mavericks and Xcode 5.1.1, I built Project B for all platforms (Release and Debug for iOS and i386) in order to debug, run tests and eventually deploy. Project B has its own set of linker flags and options that make it very special.
In project A, I would link the binaries of Project B (libProjectB.a) and it has always worked.
However, during this last iteration, Project A build process complained about missing symbols for armv7, which confused me, because project B is compiled ONLY in armv7 and i386.
The only way I manage to remove 30+ linking errors, was by linking the following frameworks:
libstdc++.6.0.9.dylib
CoreText.framework
CFNetwork.framework
Foundation.framework
I hope these don't look like random frameworks to you, but I found out by adding one by one, based on the type of linking error. For example, I added the CFNetwork only after opening the C++ code and noticing that the symbols would be part of it.
Anyway, again, I don't know why it happened yet, but it happened by using Yosemite and Xcode 6.1. Hope this can shed a light on someone.