I am linking a static framework for iOS, against an armv7 ios 6 application, I suspect that the original binaries are from XCode 3.x and were compiled with GCC, and that I'm now linking it using CLang compiler. I do not have the source code for the framework, only the binaries:
(null): warning: (armv7) /.../DerivedData/.../armv7/HardwareObjectFile.o unable to open object file
I get 69 warnings like the above, one for every .o file linked into the static framework.
Is this warning serious for any reason? I have simplified the giant path which appears to indicate that the binary files in the library have hardcoded a path in "/Users/somedeveloperthatisntme" that could hardly help but Not Exist since I'm using this library on a computer that doesn't even have a folder named "Users/somedeveloperthatisntme".
Dsymutil appears to be a tool to "manipulate archived DWARF debug symbol files", although I know precisely nothing about what it is and what it does, notwithstanding the thorough documentation from Apple, which tells me what, but never ever, why. What is it doing, and what will this warning mean for me? I suspect I need a new library/static-framework from the vendor to clear this up?
Update: I am unable to solve this and it appears the cause lays with very old binaries compiled by a very old XCODE version, shipped as part of a mobile framework from a third party vendor. The issue in this case would be resolved by having that vendor rebuild their library, something I asked them to do because the warnings drove me nuts, but which they seem unable to do. In the end I ditched their technology and replaced it with something else. (Grin)
These errors are to do with the architectures you are using and the resources you are referencing. I don't understand the reasons myself, but if you want them to go away, go to Build settings, then Build Options and then select Debug information format and select DWARF.
I am on the other side of this, building a library for others to use, and I was able to alter the library project by setting 'GCC_GENERATE_DEBUGGING_SYMBOLS = NO' in the Build Settings to make those warnings go away in an Application project that consumed the output framework.
This isn't a solution to your problem, but if you're in contact with this vendor, you could pass this along.
The other answers contain helpful information but I wish to put the real answer down succinctly:
You can not fix this, and the meaning of the errors is simple: The current linker sees these library files as containing elements that can not be opened.
To solve the warnings, contact the vendor and get a recompiled library that has been rebuilt with a later version of CLANG.
What I did was just delete the /Library/Developer/Xcode/DerivedData folder and it fixed everything for me.
Another reason these warnings could occur is because of incorrect symbol stripping settings for release builds in a project. Contact the author of the framework and tell them to make a new binary with the proper symbol stripping settings.
Related
Question stated simply in title. Here is my setup:
Building a dynamic framework that optionally links (weak link) to GoogleInteractiveMediaAds.framework. For apps that use my framework, GoogleInteractiveMediaAds is an optional dependency, and the framework will work fine without it. This is currently working.
However the problem arises when attempting to rebuild from bitcode, as typically happens when exporting an Ad Hoc build with "Rebuild from Bitcode" selected. The bitcode compile process fails with:
ipatool failed with an exception: #<CmdSpec::NonZeroExitException: $/Applications/Xcode.app/Contents/Developer/usr/bin/bitcode-build-tool ...
And looking deeper into the log file I find the error description:
Failed to resolve linkage dependency MyFramework arm64 -> #rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds: Could not resolve #rpath in #rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds from MyFramework
error: GoogleInteractiveMediaAds not found in dylib search path
Note: GoogleInteractiveMediaAds.framework does include bitcode.
Obviously this error is avoiding by not selecting "Rebuild from Bitcode". If I were to answer my own question, I'd say, no, it looks like when compiling from bitcode, you cannot use weakly linked frameworks. Simply from the fact that the bitcode compilation step is trying to link to a framework which isn't included in the app target. However I haven't been able to find any official documentation surround using weak linking with bitcode, or any relevant StackOverflow answers about it, so I'm not sure if I'm missing something or if there is some relevant compiler/linker settings that I am missing to get this to work.
In your case, you will need to wait for the fix in framework itself.
We've got similar issue while distributing our framework, which I described here and I just wan't to share results of our investigation, because seems that no-one has published their results.
No needs to distribute without bitcode. Long story short, there were LLVM instrumentation included, which prevents AppStore processing. I've written a whole blog about XCode 12 and BigSur issues with XCFramework.
To sum up, here is a few required steps to make sure while creating XCFramework for distribution:
Using archive builds is a MUST, release build isn't enough
BUILD_LIBRARY_FOR_DISTRIBUTION must be set to YES
SKIP_INSTALL must be set to NO
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO to turn off GCC instrumentation and remove them from the binary
CLANG_ENABLE_CODE_COVERAGE = NO to turn off code coverage tools from the binary
Having all of the above helped to solve our preparing and distribution problem and hopefully save you some time if you happened to face same issues as we did.
My project was building on my device perfectly fine and then all of the sudden I switched to another device and it started to give me this error.
I've removed derived data, added and removed search paths to and from $(inherited) and from recursive to non-recursive, I just don't know how to source the issue. Here is a screenshot of the error I'm getting:
As you can see, the files exist:
I just don't know why switching the device prevents them from being found on build. Even if you don't have a solution, I'd appreciate any guidance to a resource where I can learn how to solve issues like these. They happen more often than not and I don't feel I have a clear enough understanding of how things link together. Can someone point me in the right direction here?
Edit: As far as my architecture configuration, here's what I have in my project's build settings:
Edit #2: To answer the question below about my build-only architecture, it's as follows:
Go to your Project
Select your Target
Then, go to Build Phases
Open Link Binary With Libraries
Finally, just add + the framework / any other framework.
When I'm writing simple code in ViewController, I wanted to run it and boom. Apple Mach-O linker error as shown. I don't know what is the problem. Then, I've made a quick research, according to research; I deleted Derived Data folder, I deleted Derived Data folder contents, I deleted test hosts in build settings(it is already empty), I cleaned the build folder and I applied clean action. But nothing changed same errors. Is there any specific solution of this error depends on app and what is that solution?
EDIT:
I moved the codes to a new xode project and I noticed that when I add the line let ftp = CkoFtp2(), the error occurs otherwise it compiles. But it is coloring the CkoFtp() part of line and I'm not getting any specific errors there. Just Match-O and linker command.You can see the CkoFtp2 code here.
I had the same issue. Please make sure to follow the directions on chilkat's site, particularly the following:
Add libChilkatCocoa.a to your list of libs for linking. In your project build settings, find Build Phases, Link Binary with Libraries, select Add Other, navigate to the libChilkatCocoa.a, and add it.
The Chilkat library internals are written in C++. Therefore, your Swift application will need to link against the C++ runtime libraries. In your Build Settings, go to the Linking section and add -lstdc++ to the Other Linker Flags.
https://www.chilkatsoft.com/chilkatSwiftCocoa.asp
I also ran into trouble because the libChilkatCocoa.a library resided in a folder that had a space in its name. Avoid that, or make sure it is correctly escaped under Build Settings.
Looks like you've got a reference to a framework located in your Downloads folder. Chances are you moved that somewhere else, yes? Remove the SimpleUnzipper framework from the project and re-add it from wherever you moved it to.
After the edits, this is clearly not the problem...
It's hard to tell from just the error message, but it appears that you're using a library that you downloaded from another developer. Are you sure you followed their instructions for setting things up? The linker error means that you're not linking your program with the library, though it looks like you've managed to set up a bridging header so that you can call the function without getting a compiler error.
I'm having trouble linking to a static library in Xcode 5. I did read the chapter on building and using a static library in the Pro iOS 5 Tools. What it told me to do after creating your static library, was to link against the framework in the Build Phases tab. That part is pretty straight forward. Then it says in the Build Settings, under "Header Search Paths", to add:
$(BUILT_PRODUCTS_DIR)
Then in order to use my static library, I just import it like so:
#import "ConversionCalculator/ConversionCalculator.h"
So this used to work up until yesterday. I tried adding a new static library to my project which didn't seem to work. So I cleaned my project, and tried rebuilding again, but now Xcode complains about #import "ConversionCalculator/ConversionCalculator.h". It says
Lexical or Preprocessor issue. 'ConversionCalculator/ConversionCalculator.h' file could not be found.
I was wondering if anyone has any tips on debugging this. I've looked through different tutorials like this:
http://blog.stevex.net/2012/04/static-libraries-in-xcode/
http://cocoamanifest.net/articles/2011/06/library-management-with-xcode-workspaces.html
http://www.raywenderlich.com/41377/creating-a-status-library-in-ios-tutorial
But I can't seem to find the "golden way" to link to a static lib, or how to troubleshoot why Xcode cannot find my file. My file structure is setup on my machine like so:
Projects\
DistanceCalculator\DistanceCalculator.xcodeproj
ConversionCalculator\ConversionCalculator.xcodeproj
DistanceCalculator.workspace
Like I said, this all used to work too when I followed the tutorial in Pro iOS 5 Tools book. Now I don't know why my workspace cannot find ConversionCalculator when it has used it before. The part I find hard is different articles say different things about the header search path, and I'm not sure what the best way to populate that field is. Any thoughts? Thanks in advance!
Edit:
I'll add that I can build for the device without errors. But when I switch to the iPhone simulator, it gives me that error about not being able to find the file. I also see that I get this warning:
ConversionCalculator was rejected as an implicit dependency for 'libConversionCalculator.a' because its architectures 'i386' didn't contain all required architectures 'i386 x86_64'
Looking at that, I'm not sure what that means. If it means that my library is not being built for all architectures, I just tried creating a Target that builds for all architectures according to the wenderlich article in the above link. That seems to work as when I go to the dervieddata folder, I see for debug, release, and universal, I see the libConversionCalculator.a file. But then when I go back into the workspace and try to rebuild the project for the simulator, I get that could not find file error and the implicit warning.
Edit #2:
I just saw a warning flag on Xcode that says upgrade to recommended Build Settings. Now I get no errors. Not sure what happened... but I guess no errors is good.
I would follow the description available in Xcode's Help topic "Linking Against Your Library" in chapter Configuration Your Application in Introduction to Using Static Libraries in iOS
(you may search within Xcode Help, too).
Except that I would recommend to include your headers from libraries always using angle brackets:
#import <ConversionCalculator/ConversionCalculator.h>
Using double quotes may inadvertently search and find files with the same name in some sub-folder relative to the file where this import directive is written. Only after there was no file in any sub-folder the preprocessor starts searching with the specified header search paths.
Using angle brackets, the preprocessor immediately searches only at the specified header search paths.
So, since you actually want to find headers for the corresponding library, always use angle brackets.
Note: If you follow the recommendation to create a static library project, you don't need to explicitly set a header search path in the target that links agains the library: Xcode will already add a search path:
$(BUILT_PRODUCTS_DIR)/includes
Your library headers are located in
$(BUILT_PRODUCTS_DIR)/includes/<product-name>
which are placed there through the "Copy-Files" phase of the iOS static library target, whose "Destination" is set to "Products Directory" and whose "Subpath" is set to "includes/${PRODUCT_NAME}" per default.
You may change these default settings to other reasonable and sensible values. (if you do, consider the the consequences for Xcode's default search paths!)
I have been given the task of adding a few features to an iOS app. I checked out the source on SVN to be greeted with over 100 warnings (argh), thankfully I'm down to the last one, which is:
(The blocked out bits are the client name...).
I believe this warning is saying something along the lines of: 'this XML library is not compatible with the OS architecture that is being linked on the build'.
With the next release, we are supporting only iOS5 and iPhone 4 and above (rather than lower versions of iOS and older iPhones).
So do I change the link architecture? What is the link architecture? How do I change the architecture? Or am I completely on the wrong track?
May be worth mentioning that I am running the latest Xcode, I've added the framework from the Xcode list (link binary with libraries).
EDIT
I only get the message when building from the simulator. It doesn't cause any harm, just winds me up!
Thanks in advance.
Do not link against libxml2.2.dylib, instead link against libxml2.dylib. Linking against that should ensure you are always linked against the correct implementation for your architecture.
As a general rule, in your applications link to the generic version of a library rather than a specific version. In this case this means libxml2 rather than libxml2.2 .
You are linking to a (symlink to a) dynamic library which at runtime will automatically point to the correct implementation for the current OS version and architecture. Linking to the specific version of a library does not guarantee this, and you can end up linking to a something that only has a single architecture. Thus, during development if you link to libxml2.2.dylib when targetting the simulator you may be linking against something that is i386, then when you target a device it can't find the correct architecture (because it's trying to use i386 for armvWhatever, which is exactly what you are telling it do).
If you're trying to use libxml2.2, it's already available in Xcode. Instead of getting it from an outside source (Apple wouldn't let you use a dynamic library anyway), add it in Xcode to your frameworks, and then link it by adding /usr/lib/libxml2/ in Header Search Paths. Don't link your project with a dylib that's not Apple provided or else your app will get rejected. Also, the architecture i386 isn't the architecture for iOS, as iOS uses the armv7 and armv7s architectures for the newer versions of their devices, which is why you are getting the architecture warning.
Basically the difference between libxml2.2 and libxml2 is that libxml2.2 points to a specific version/implementation of libxml whereas libxml2 is a shortcut/symlink that points to the latest version AND correct architecture of libxml2 that XCode can find. Therefore when adding a framework like this, you should always add the 'general version' (the symlink) of it (libxml2) rather than the 'specific version' of it (libxml2.2) because of the exact issue you're seeing.
Hope this helps!
That says you're linking to something built for 386 not arm.
You will either need a different dylib to link to or go into project settings and change the arch. ( if you are building the dylib)
Probably to include arm7 or similar.