i tried to implement DTCoreText. I follow this guide and implemented it as git submodul, but now i get an error when i try to run my app. At the Moment i´m not doing any coding with DTCoreText. I just want to test my app if it works with the new imported Data...but it do not!
I got one warning:
Static Library was rejected as an implicit dependency for 'libDTCoreText.a' because its architectures 'armv7s' didn't contain all required architectures 'armv7'
which is in my opinion the reason for the following error which occour after the warning:
Apple Mach-O Linker Error: no such file or directory: '/Users/-------------/Build/Products/Debug-iphoneos/libDTCoreText.a'
I did not forget to implement the libDTCoreText.a in "Link Binary With Libraries", but it is always red? Is this maybe the Problem?
I had a similar issue and I had to check "Build Active Architecture Only" on each of the Project configurations (Debug, Release and Deployment) and in the Build Settings of the DTCoreText project targets.
https://www.dropbox.com/s/00oktoqgse83sph/Screenshot%202014-08-07%2014.08.47.png
https://www.dropbox.com/s/gcy6ynrzqs8i7c1/Screenshot%202014-08-07%2014.10.39.png
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.
I updated Xcode to version 11.1 and got this expected error:
WatchKit is not available when building for iOS Simulator.
Then I deleted WatchKit from iOS app target as suggested. Since then I am having this error:
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_WKInterfaceController", referenced from:
objc-class-ref in INFOnlineLibrary(IOLWatchKitHelper.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
Undefined symbol: _OBJC_CLASS_$_WKInterfaceController
PS: The x86_64 part is dependent on the device/simulator choice. If I choose a real device it gives the same error for arm64. So I don't think it is a architecture issue also because of the fact that the framework that includes WKInterfaceController is just a standart watchOS framework which is Watchkit.
PS_2: There is no use of WKInterfaceController or even WatchKit in the iOS app. It is only used in WatchAppExtension part
What I have tried so far:
First thing was to add WatchKit framework to WatchApp and
WatchAppExtension targets.
When I searched for Undefined symbols for architecture x86_64 type of errors in general there were many different suggestions. Even though I think it is not architecture dependent thing, I tried setting building active architecture only no in all targets. The most suggested putting $(inherited) to the search paths was already done before.
Checked the target of .m files. They are all fine.
I even went far and commented all the code that is using WKInterfaceController. Nothing has changed after. I also deleted watch app, it still looked for _OBJC_CLASS_$_WKInterfaceController but I am not sure did it properly.
I checked the WatchKit.framework Device Supporting Files with file WatchKit.framework command and saw that it supports arm64. Then added that library manually to libraries, ran on device but still didn't work.
When I saw this error, it turned out to be because one of my .mm implementation files was not checked in the "Target Membership" section of the options pane, and so was not being built.
Please check "Link Binary With Libraries" in "Build Phases". Is there any library that used still WKInterfaceController or is dependent on the WatchKit?
I was getting the same error though with another framework. You just have to make sure that error files have the required framework is in your Link Binary with Libraries.
In my case I had the error Undefined symbol: OBJC_CLASS$_SKStoreProductViewController which is related to StoreKit.
All I had to do was add the StoreKit.framework into Link Binary with Libraries
I faced a similar error, but in my case it was probably some unclean library lying around after adding / removing dependencies. So I did Xcode -> Product -> Clean Build Folder , and rebuilt the project. It succeeded.
I had to drag & drop the framework into Xcode, under the Frameworks group. It was already added under Target > Build Phases > Embedded Frameworks, but apparently that wasn't enough.
If you are sure that implementation files are checked in the "Target Membership" section of your app for the build, make sure that there is an implementation of the header file somewhere. I ran across this issue when I had a class that I had defined within the same file as another class and forgot to put its implementation in the related .m file for both classes.
I have upgraded to XCode 8.0 and it is giving me grief. The first issue was to do with code signing. Which I fixed by selecting a provisioning profile for debug and release from the General project settings. Weird not sure why it couldn't just work as it was compiling perfectly with the previous XCode. Previously XCode would say there is not provisional profile and prompt to fix it and would fix it. Seems a step back here. Anyways, went passed that issue.
The issue I have been facing all day is this error when I compile
Undefined symbols for architecture arm64:
"_write_ret", referenced from:
_dwsl in libtestlib.a(testlib.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I searched for write_ret and it is only a prototype in a header file, this function isn't called anywhere at all!! (Background the static library is part of a bigger project I brought only the files/code I needed to compile the static library for iOS). This was compiling perfectly before for years. I went back to the static libary source code and to humour myself I deleted the write_ret prototype and compiled it and updated the library in the my project and rebuilt. Same error again!. What is going on here?? I confirmed it was definitely using the correct built library.
I then decided I'll just built for armv7 only as this is an enterprise app. I went back to the static library project file and got rid of armv7s and arm64 from "valid architectures". I change "architectures" to armv7. I rebuilt the library and updated the project with the new library.
I also went into the main project and change the valid architectures to build for only armv7.
This time when I built my project I get this error
ld: warning: ignoring file /Users/rrr/Library/Developer/Xcode/DerivedData/P-eaxegvaceikvgqgllfiardmoorbv/Build/Products/Debug-iphoneos/libtestlib.a,
file was built for archive which is not the architecture being linked (armv7):
/Users/rrr/Library/Developer/Xcode/DerivedData/P-eaxegvaceikvgqgllfiardmoorbv/Build/Products/Debug-iphoneos/libtestlib.a
In the terminal I ran lipo libtestlib.a -info I get this:
input file libtestlib.a is not a fat file
Non-fat file: libtestlib.a is architecture: armv7
So it is built for armv7, so what is XCode complaining about really?
I am out of ideas now. Can anyone shed some light here?
I would like to get it to work with all the architectures as it was doing before the XCode upgrade I did on Friday. But worst case atleast compile to work only for armv7. My understanding is that it will still run on anything iPhone 5s and newer anyway.
At first, As you already know, you should support arm64 in order to support 64 bit architecture following Apple's rule.
At second, let's talk about undefined symbol issue, your first question.
I am not sure exactly from your situation description but, one thing to my mind reading the question is that your static library may depend on some dylib(dynamic or shared library) which is deprecated from Xcode 7.The possible scenario is your dylib library was red-marked in the project from Xcode 8 update version because this was replaced with tbd instead of dylib. So, this library is now missing status, and you did remove it in the library list and you forgot it. That's why your _write_ret symbol in libtestlib.a cannot be linked for architecture arm64 anymore.(dylib is missing status.)
if this scenario is true, import tbd instead of dylib.(text-based stub libraries).
let's talk about your second question related to error log.
ld: warning: ignoring file /Users/rrr/Library/Developer/Xcode/DerivedData/P- eaxegvaceikvgqgllfiardmoorbv/Build/Products/Debug-iphoneos/libtestlib.a,
file was built for archive which is not the architecture being linked (armv7):
/Users/rrr/Library/Developer/Xcode/DerivedData/P- eaxegvaceikvgqgllfiardmoorbv/Build/Products/Debug-iphoneos/libtestlib.a
This log can be about Build Active Architecture Only in Xcode build setting.
check 'Build Active Architecture Only' from Yes to No.
It error log could be generated when Build Active Architecture Only is set to YES in your build setting situation.
and, if it does not work, Have you ever clean your DerivedData directory and project?
If you already tried, it could be possible that your static library is actually not in the /Users/rrr/Library/Developer/Xcode/DerivedData/P-eaxegvaceikvgqgllfiardmoorbv/Build/Products/Debug-iphoneos/libtestlib.a.
so, you can move your static library output into this project and try it again.
These are just scenario for your situation as I got your question.
I wish it became a little help.
Thanks.
I have been working on reviving an older open source project, and when I updated the architecture from $(ARCHS_STANDARD_32_BIT) to $(ARCHS_STANDARD), Xcode gave me a very long error with the title Apple LLVM 6.0 Error which ended with the line Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1. I tried undoing the architecture change, but it still gave the error when I ran it again.
The previous build worked perfectly, and the only changes that were made on the erroneous build were:
1) I moved the project to Dropbox
2) I changed the architecture
Here is the full error: http://pastebin.com/huLnWc7v
Try This , It may solve your problem.
Issue: Compiler unable to locate .pch file. This is because Location of Prefix Header file .pch in Project Target is incorrect.
The location is defined in Project Target/Build setting. You will need to go to: Project Target -> Build Settings Tab -> Scroll down and Look for "Apple LLVM Compiler 6.0 - Language" Underneath this node -> You will find the key/value setting for Prefix Header file.
Normally Prefix header file is located under "Supporting File" Folder in your project
Reference : Anbu.Karthik
I was trying to compile ARM code as if it were ARM64. Since it's just an app and not an extension, I don't need to do that. So, under Project>Target>Build Settings> Architectures I changed the Architectures key I standard architectures, and the Valid Architectures key to armv7.
I'm running an app that uses EAAccessoryManager, which should only be available via the ExternalAccessory framework. Yet it compiles and runs without ExternalAccessory being included in the list of frameworks to link. Nor is it loaded into Xcode by any other targets. How is this possible? I'm mystified.
I'm curious because I have another project that loads a static library that also references EAAccessoryManager, and in that case, the app won't compile, exiting with the error Undefined symbols for architecture i386. This is more what I expect. What can account for the difference?
Could be a linker build setting rather than a link build phase.
In Build Settings, in the “Apple LLVM 5.1 – Languages – Modules” section, “Link Frameworks Automatically” is enabled:
This is a new feature I never noticed before discovered while reading this post on #import (thanks #RhythmicFistman for the hint!). When I change that setting to “No”, I get the linker errors I expect.