I'm trying to integrate a prebuilt a static c library (a .a library )into my Xcode 5 project. But it failed and returned tons of Apple Mach-O linker errors. What I did is I added the Library Search Path to correct path and added the Other C flags, Other C++ flags as something like -lmylib ( the lib file name is libmylib.a). I remembered it worked in my previous Xcode which using GCC.
Can anybody advise what I should do to fix the problem. Thanks.
Edit:
By adding these flags to Linker flag solved the problem. But I have another issue. The .a built for normal simulator doesn't work for the one with 64 bit. How should I solve this problem?
My bad. Add the flag to the wrong place. Should add to Other Linker Flag.
Related
I try to make macOS GUI application with ffmpeg.
On project settings -> General -> Frameworks,Libraries..., I added the ffmpeg lib files
/opt/homebrew/Cellar/ffmpeg/5.1-with-options_2/lib/libavutil.57.28.100.dylib.
I also add lib search path of /opt/homebrew/Cellar/ffmpeg/5.1-with-options_2/lib
I still get error : Library not found for -lavutil.57.58.100.
I like to get more detail about error.
I think these possibility
not valid arm64 format.
linker expect x64 and arm64 binary. But the file has arm64 only.
Dependency of dylib is missing.
If someone knows solution or detail about this error, please let me know.
That file exist and valid arm64 Mach-O file.
file libavutil.57.28.100.dylib
libavutil.57.28.100.dylib: Mach-O 64-bit dynamically linked shared library arm64
Some tips that will help you to troubleshoot this issue.
Firstly, lldb expects an arm64 version of the lib if your main executable's architecture is arm64, a fat-universal version of the lib if your main executable's architecture is fat-universal.
So please check the main executable's architecture inside YOURAPP.app/Contents/MacOS. I'm taking IINA video player as an example:
lipo -i /Applications/IINA.app/Contents/MacOS/IINA
Secondly, it's not good to refer to a brew version of the binary. If the library's version on another machine mismatches with yours, your app will crash. It's ok that you copy the dylib file and copy it into your Xcode project. Then you can add the dylib file to the Frameworks, libraries, and Embedded Content section in Xcode. The below image shows an example of integrating ffmpeg libs into your project.
Alternatively, the ffmpeg-kit package is your friend. I have a simple showcase for you: Github
Finally, if you insist on using the brew version, please disable checking on code-signing for external libs: Project Settings > Signing & Capabilities > Hardened Runtime > Runtime Exceptions > Diable Library Validation
Xcode does not add library search path.
I add -L/opt/homebrew/Cellar/ffmpeg/5.1-with-options_2/lib on "Other Linker Flags"
I'm trying to compile a simple Boost Wave example and while Xcode is recognizing the headers, it is giving me a slew of Apple Mach-O Linker(Id) Errors. I have encountered this before and I don't remember how I solved it. Please help!
I have attached a screenshot.
P.S. I have Boost 1.57.0 and it works just fine with any Xcode Project. For whatever reason, though, it isn't in the case when it involves the header boost/wave.hpp like so...
#include <boost/wave.hpp>
Also, I ruled out the body of the code as a culprit. This throws the linker erros:
#include <boost/wave.hpp>
int main() { return 0; }
Other Boost headers like these, do not:
#include <boost/function.hpp>
int main() { return 0; }
I figured it out, but have no idea why this is the case. If anyone would like to add an explanation, that would be splendid. I had to manually add the various dynamic and static libraries referenced in each of the above issues. I attached a new screenshot so others having this issue can see the end result.
Well, the explanation is very simple. In order to be able to build your project, the compiler working under the hood needs to know:
Where to search for the #include <..> within your project's files: this corresponds to the -I directory option for the g++ compiler. In Xcode this corresponds to set the "Header Search Paths" in the Build Settings of you project.
Without specifying the Header Search Paths, you will get errors on the #include lines since Xcode doesn't know where to look for those included files.
Where to search for the library that must be linked to your source code while building the project: this corresponds to the -L directory option for the g++ compiler. In Xcode this corresponds to set the "Library Search Paths" in the Build Settings of you project.
Without specifying the ** Library Search Paths**, you will get errors while trying to build your project since Xcode doesn't know where to look for the linked libraries.
What libraries must be linked to your project files at compilation time: this corresponds to the -l linking option for the g++ compiler.
In Xcode this corresponds to add the .dylib files to the Link Binary With Libraries in the Build Phases settings of your project. Note that you don't need to add manually the libraries to the main folder of your project, the last described step suffice.
See here and here for the directory and linking options of the g++ compiler, respectively.
I am a noob and am having an issue with linker flags.
I tried building my own ssh2 libraries, and then afterwards I cloned a git repository with a project in the libraries already built.
Before I downloaded the compiled binaries, I was building with gcrypt and added the -lgrcrypt library to the other linker flags.
With this new library set that I am using, I no longer require gycrpt and so I removed the linker flags. However that did not clear the linker options. I am still getting all of the old linker flags in spite of clearing them in the project properties.
The error shows that the -lgrypt is still being processed as a linker flag:
-no_implicit_dylibs -mios-simulator-version-min=6.0 -lgcrypt
How can I reset the linker flags to what they were?
Thanks in advance
well i presume you have checked the flags and removed the path for that lib in your target level of the project, and also have clean the build and removed the previouse builds from organizer and inside xcode, and also have reset your simulator, and also have checked the project folder on your computer and removed that lib from the library folder of the project. these are the necessary steps and if you have done all of these then i cant think of anything else other than port your code to a new project and try to compile again. good luck my friend.
I have another OSX application problem. I want to bundle in my final application several dylibs, all of them needed by the application and by other dylibs.
I change its references using the install_name_tool, but some of the libraries couldn't be changed properly, having this error:
install_name_tool: changing install names or rpaths can't be redone for: aLibrary.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
So I added the headerpad_max_install_names option flag on the linker flags of the xcode project (Project Properties-Build Settings-Linking-Other Linker Flags). Also I verified in the build log, if the option flag was included, and the option flag was included properly.
But still having the same error in the last dylibs.
Is there any way to bundle all the libraries needed in a unique Framework? Or am I doing something wrong in the building process?
Hope I'm clear with the main problem.
Thanks!
I had this same problem, using C++ and Code::Blocks, and I fixed it by switching from g++ to clang++
I've set LIBRARY_SEARCH_PATHS to /opt/local/lib, and verified that the library in question is there (I'm linking to GLEW):
$ls /opt/local/lib
libGLEW.1.5.1.dylib libfreetype.a libz.a
libGLEW.1.5.dylib libfreetype.dylib libz.dylib
libGLEW.a libfreetype.la pkgconfig
libGLEW.dylib libz.1.2.3.dylib
libfreetype.6.dylib libz.1.dylib
but Xcode gives me the linker error
library not found for -lGLEW
I'm generating the Xcode project with CMake, so I don't want to explicitly modify the Xcode project (if someone suggests adding it as a framework, or something like that). Xcode recognizes USER_HEADER_SEARCH_PATHS fine (as in this question); why doesn't it work here?
Perhaps adding something like this to your CMakeLists.txt?
find_library(GLEW_LIB GLEW /opt/local/lib)
if(NOT ${GLEW_LIB})
message(FATAL_ERROR "Could not find GLEW")
endif()
target_link_libraries(myprogram ${GLEW_LIB} ...)
Where myprogram is the name of the target executable that needs to link with the library. You would replace the ... with the other libraries you are using on that executable.
This way CMake would handle the library path details for you.
Xcode works on potentially multiple SDK's, so whenever your define these kinds of things (like HEADER_SEARCH_PATHS or LIBRARY_SEARCH_PATHS) the current SDK root is prepended to the actual path that's getting passed to the linker.
So, one way to make this work would be to add your directory to the SDK. For example, assuming you're building with the Mac OS X 10.5 sdk, you could add your opt dir:
ln -s /opt /Developer/SDKs/MacOSX10.5.sdk/opt
Your library would now be found on your system.
If you don't want to do this, then you will have to look at CMake and find out how to get it to generate a library requirement for your actual library (I don't know anything about CMake, so I can't help you there). This is also why you see a difference between USER_HEADER_SEARCH_PATHS and HEADER_SEARCH_PATHS re your other question.
As another option, you could also specify this path with the OTHER_LDFLAGS build variable:
OTHER_LDFLAGS=-L/opt/local/lib
This would cause the linker to search /opt/local/lib as well as its standard paths and wouldn't require you to generate a different project file.