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.
Related
I've been recently trying to transfer my Visual Studio OpenGL project to VS Code, using GCC via mingw-x64 on Windows 10. I've been making steady progress working this all out as I am fairly new to c++ programming, and I've been running into an error that I can't solve.
When building with the following command:
C:\Lib\mingw-w64\mingw64\bin\g++.exe -LC:/Lib/lib -IC:/Lib/include -g main.cpp -lglew32 -lglfw3 -lSOIL -lopengl32 -o build.exe
I've been getting this error:
C:/Lib/lib/SOIL.lib: error adding symbols: File format not recognized
collect2.exe: error: ld returned 1 exit status
The SOIL.lib I am using worked fine for Visual Studio, and GCC seems to have no complaints with the other .lib files I am using.
There doesn't seem to be much information about what's happening, I've found a bunch of different people having the same error for different things, and I haven't been able to work out what is actually going wrong for this cryptic error message. Can anyone help out?
*.lib: error adding symbols: File format not recognized.
is the issue which is caused by your linker. The reason behind this is the library is belongs to other architecture rather than you are intended it to be.
That means you are using mingw64\bin\g++.exe compiler(mingw64 architecture) and the library SOIL.lib is built for your host system architecture(which is obviously different than mingw64 architecture).
If you want to compile this you have to get the SOIL.lib built for mingw64.
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.
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.
I've previously compiled OpenCV 3.0 successfully following this guide, which essentially consists of the following steps:
Download all the prerequisites (XCode, Command Line Tools, CMake and OpenCV source)
Build static libs by configuring CMake (via gui) with:
Uncheck BUILD_SHARED_LIBS
Uncheck BUILD_TESTS
Add an SDK path to CMAKE_OSX_SYSROOT (if it matters, I used /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk).
Add x86_64 to CMAKE_OSX_ARCHITECTURES (emphasis mine, this seems to be the issue, I'm sure I've followed this step)
Uncheck WITH_1394
Uncheck WITH_FFMPEG
Configure and generate via CMake, then make and sudo make install from the CLI.
All of the above alone works fine.
I'm now looking to compile OpenCV with the extra modules. According to their read-me it should be as simple as filling out OPENCV_EXTRA_MODULES_PATH to <opencv_contrib>/modules in CMake and then building as usual.
I followed the steps outlined above with the added parameter and building OpenCV succeeds, however, when trying to use one of the extra modules in a program (namely cv::ximgproc::createStructuredEdgeDetection, if it matters), I'm getting the following error when compiling:
Undefined symbols for architecture x86_64:
"cv::ximgproc::createStructuredEdgeDetection(cv::String const&, cv::Ptr<cv::ximgproc::RFFeatureGetter const>)", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've included the header which should include the above:
#include <opencv2/ximgproc.hpp>
I'm compiling via XCode, where I've set an additional header search path of /usr/local/include and a library search path of /usr/local/lib for the project, am I missing something here?
Standard OpenCV functionality works fine.
What could be the issue and how would I go about solving it?
OpenCV contrib modules are built correctly.
You just need to add the contrib libs to your dependencies, in this case adding: -lopencv_ximgproc.
All available libs can be found under <OPENCV_DIR>/install/ folder.
E.g. in my 32bit vc12 static build are in<OPENCV_DIR>/install/x86/vc12/staticlib folder.
I'm trying to receive information from an 0MQ Socket in C or C++, but therefore I have to include zmq.h. By downloading the 0MQ software from their website and including this file. Xcode gives the following error:
Undefined symbols for architecture x86_64:
"_zmq_init", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
When installing ZeroMQ using brew I get the same error. Is there anyone who know a workaround?
The problem here is that you aren't linking the ZMQ library correctly.
You need to build the library once you've downloaded it (they include all the make scripts you need). Once you have that, you will need to link them to the compiler. I'm not too familiar with XCode, but using gcc it would look something like this:
-L/path/to/zmq/library -lzmq
ZeroMQ is really beautiful though. I've used it on Linux/Windows. Hope you get it working!