Linker Error - Project not cleaning entirely? - ios

I'm going to apologize in advance here. The project I'm working is under a couple NDAs so I'm not going to be able to be as specific as I would normally want to.
I'm working on an iOS project that includes a pre-compiled library in the form of a .h and .a file. I started development with a particular version of this library and everything was working fine. They've since released a new version that I need for a particular new feature.
Between the old and new versions, several of the function names have changed. When I update my code to call the new methods, I'm getting an Apple Mach-O Linker Error at compile time: (Names have been changed to protect the innocent)
Undefined symbols for architecture armv7:
"methodName", referenced from:
myMethod() in MyClass.o
ld: symbol(s) not found for architecture armv7
collect2: ld returned 1 exit status
I know it looks like it just doesn't include armv7 code, but that's actually a red herring. If I set the architecture build setting for both the project and target to Standard (armv6 armv7), I get the same linker error, except it'll say armv6.
The problem is, I can put the new .h and .a files in a new project and call this same method and not get the linker error!
I have a feeling that there's something that isn't getting cleaned and it's trying to compile against the old .a file. I'm using Xcode 4.1 on Snow Leopard. I've tried removing the file from the project, deleting the .a file from the Link Binary With Libraries section under Build Phases for the target, cleaning, adding back the .a file and rebuilding and I still get the error.I'm starting to go crazy here.

OK - I found the culprit! Naturally, it was in Build Settings.
When I switched to the new version, I put the new library in a folder next to the old one, in case I had to switch back at some point. Apparently, when I removed the old version, it did not remove the path to the old version of the .a file from Library Search Paths in the build settings for the target. Deleted the old path, everything is working again.

Related

Undefined symbol: _OBJC_CLASS_$_WKInterfaceController error after updating Xcode to version 11.1

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.

Mach-O Linker error, undefined symbols for architecture after upgrading xcode to 8.0

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.

Xcode 6 linker error - Undefined symbols for architecture armv7

After upgrading to Xcode 6 beta 7 (and now still with Xcode 6 GM) I am unable to link my Swift app. I receive errors such as:
Undefined symbols for architecture armv7:
"_swift_stdlib_compareNSStringDeterministicUnicodeCollation", referenced from:
...
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I have seen the other SO posts that recommend deleting the Derived Data folder and/or using the Clean Build Folder option to get past this error, but that solution didn't help at all in my case. Nothing has changed about my code or the CocoaPods I'm using since Xcode 6 beta 5 which is the last time it worked.
Any ideas?
EDIT:
A full posting of the error log:
Undefined symbols for architecture arm64:
"_swift_stdlib_compareNSStringDeterministicUnicodeCollation", referenced from:
TFC12MyProject21BarcodeViewController13captureOutputfS0_FTGSQCSo15AVCaptureOutput_24didOutputMetadataObjectsGSQGSaPSs9AnyObject___14fromConnectionGSQCSo19AVCaptureConnection__T_ in BarcodeViewController.o
"__TFSs21_arrayConditionalCastU___FGSaQ__GSqGSaQ0_", referenced from:
TFC12MyProject27SessionsTableViewController17viewWillDisappearfS0_FSbT_ in SessionsTableViewController.o
"__TFSs15_arrayForceCastU___FGSaQ__GSaQ0", referenced from:
__TFC12MyProject7RestApi12tokenMappingfS0_FT_CSo15RKEntityMapping in RestApi.o
__TFC12MyProject28AttendeesTableViewControllerg24fetchedResultsControllerCSo26NSFetchedResultsController in AttendeesTableViewController.o
__TFC12MyProject27SessionsTableViewControllerg24fetchedResultsControllerCSo26NSFetchedResultsController in SessionsTableViewController.o
__TFC12MyProject21BarcodeViewController13startScanningfS0_FT_Sb in BarcodeViewController.o
"__TFSs26_forceBridgeFromObjectiveCU__FTPSs9AnyObject_MQ__Q_", referenced from:
__TFC12MyProject7RestApi12resetRestKitfS0_FT_T_ in RestApi.o
__TFC12MyProject16BluetoothManager17_startAdvertisingfS0_FT_T_ in BluetoothManager.o
__TFC12MyProject19LoginViewController32registerForKeyboardNotificationsfS0_FT_T_ in LoginViewController.o
__TFC12MyProject19LoginViewController35deregisterFromKeyboardNotificationsfS0_FT_T_ in LoginViewController.o
__TFC12MyProject19LoginViewController16callProcessLoginfS0_FT_T_ in LoginViewController.o
__TFC12MyProject21CheckinViewController16enableBeaconModefS0_FT_T_ in CheckinViewController.o
__TFC12MyProject21BarcodeViewController13startScanningfS0_FT_Sb in BarcodeViewController.o
...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
What's happening here has nothing to do with your Derived Data location.
When a swift application is built, it goes through several steps:
Write auxiliary files
Create product structure
Compile swift source for each architecture
Copy resource rules plist
Copy application bridging header
Link against swift runtime libraries for each architecture
Copy application swift module for each architecture
Create the application binary
Copy resources build phase
Copy the swift standard libraries into the application
Package it up
Sign it
Whew! That's a lot. Your build is failing when linking against the swift runtime libraries. They live in Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos inside the Xcode developer directory. Specifically, the library that is not being correctly linked is libswiftCore.dylib. If you use nm on that library, you can see it defines your first missing symbol:
quellish% nm /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib | grep compareNSStringDeterministicUnicodeCollation
00197c8c T _swift_stdlib_compareNSStringDeterministicUnicodeCollation
000000000018352c T _swift_stdlib_compareNSStringDeterministicUnicodeCollation
You can also use lipo to see what architectures are in the file:
quellish% xcrun lipo -info /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib
Architectures in the fat file: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/libswiftCore.dylib are: armv7 arm64
It contains armv7 and arm64. It's not the library architecture that's the problem.
Linking against the swift standard library is not working. It's possible that source control or migrating Xcode versions has caused your project file to drop part of the linking step, or it's simply not able to find the libraries it needs to link against. Xcode project files are complex and use a lot of references - it's possible that a merge, etc. caused a critical reference to be come dissociated from the linking step. Without a full build log and a look at your machine it may not be possible to tell.
This library, as you might guess, has nothing to do with the project's derived data location.
The best way to move forward would unfortunately be to recreate the project file. Comparing the build log of the broken project to a swift project that does build correctly may provide some insights, but it may also be a waste of time - something fixable may be the problem, but more likely not.
I would encourage you to file a bug and include the troublesome project file with it.
I have solved my issue by deleting all the data in the ~/Library/Developer/Xcode/DerivedData folder. I read about that in another thread, but ignored it thinking a clean included that process!
I have Updated on Yosemite, Xcode 6.1.
I have updated gem xcodeproj (0.19.4) and cocoapods (0.34.4).
I have resolve my conflict by :
Clearing the Library/Developer/Xcode/DerivedData folder
replace in Target -> Build Settings -> Linking -> Other Linker Flags : $(OTHER_LDFLAGS)
Check in Target -> Build Phases -> Copy Pods Resources : "${SRCROOT}/Pods/Target Support Files/Pods/Pods-resources.sh"
1) I face the same problem but just clear the applications from derived data from User/Library/Developer/Xcode/DerivedData and I am able to run the code.
2) In your case may be, it will run by removing armv7 architecture from build settings. And make sure your compiler is Default Compiler in Build Settings.
Thanks I hope this helpful to you and everyone.
This seems to be caused (for most) by linking a third-party library that does not support the requested architecture.
I had somewhat similar problem (a linker error from Apple's framework). As it turned out, the problem was that I was missing the library LocalAuthentication.framework. I am wondering if maybe you need to delete the Foundation.framework from the Build Phase tab (in the Link Libraries section), and then re-add it? Maybe that will solve the problem?
'Upgraded' to xcode 6 and swift app wouldn't build for simulator yet would build fine on an iPad - Linker error, undefined symbols for i386 for the simulator.
Clearing the Library/Developer/Xcode/DerivedData folder worked for me.
There appears to be a bug in Xcode 6.0.1 that is causing the linker to drop dependencies in existing project files. I have had this same problem across several different projects, new and old, since the 6.0.1 update.
The easy 'fix' is to just trash your entire 'Derrived Data' and all build files (i.e. manually clean the project) and then rebuild after a fresh Xcode restart. Magically, the linker now finds all the missing architectures/symbols.
NOTE: I have had several incompatible v-table crashes caused by this same bug. The C++ linker appears to be generating incomplete linkages, causing absurd errors where there are no real errors to be found. Again, just rebuild from a clean state and .. ta da.. save yourself a LOT of headache and wasted time tracking down a non-issue.
I solved this issue after trying all that was suggested here with no luck.
Like someone said earlier, it's a SourceControl issue.
One of my project files (the one referenced in the error message) was missing from the project browser. However, XCode still had a reference to it (I was going to the class definition when I was selecting "jump to definition" from Xcode GUI).
As a matter of fact, the project.pbxproj was not listing it. This was probably a Git Issue. In any event, I just recreated the file in the same directory it has been recreated and voila.
I am a filly when it comes to iOS Objective C, though I have been coding in several other languages for many years. So I am stabbing around in the dark most of the time with Objective C.
I started having this error, "Undefined symbols for architecture armv7", directly after declaring some "global" variables in my .h file like so:
extern NSString *globalNotes;
extern NSString *globalUserCountry;
I was then referring to these variables from the .m file like so:
globalNotes= #"Error (Marker 1010)";
globalUserCountry= #"No result";
THE FIX - To correct this, I changed them to object properties like so:
#property(nonatomic, strong, readwrite) NSString *globalNotes;
#property(nonatomic, strong, readwrite) NSString *globalUserCountry;
And referred to them like so:
self.globalNotes= #"Error (Marker 1010)";
self.globalUserCountry= #"No result";
That seemed to fix my problem.

iOS project builds for armv6 when armv7 is specified (target is iOS 5.1)

I get a long list of errors that spit out (for every source file I have) linker errors to the .o files (stemming from said sources). The error for every one basically resolves to this:
CompiledSource.o, file was built for i386 which is not the architecture being linked (armv7)
Except that the issue is actually warning, technically. However, at the end of compilation/linking phase the project refuses to build with a simple Linker command failed with exit code 1 error.
I've been spending the past 2 hours trying to figure this one out.
In Targets->ProjectName->Architectures->Valid Architectures I have both armv6 and armv7 selected. I ALSO have my build target set for iOS 5.1.
In my Targets->ProjectName->Build Phases->Copy Bundle Resources, I have all of my resources added (I assume this is where resources such as image and nib/xib files are added).
Is there anything I can do about this? I've tried cleaning the project, removing all files from DataDerived folder in XCode root, and even cleaning out /var/folders. Admittedly, this project hasn't been touched since at the very latest 2011.
I should note that I'm pretty new to iOS stuff (as well as Xcode). Unfortunately, this project is under an NDA as well so I can't reveal too much info. However, if anyone has any questions I will answer the best I can.
Are you sure its an iOS application? Because that sounds like its linked to a custom framework that got build for i386 (OSX-intel) which would probably never work on iOS.
Did you try to Product->Clean? or [alt] Product->Clean Build Folder ?
Maybe have a look at some example code from apple and see how these iOS projects are struktured.

Static lib linking error: Symbols not found for architecture

I need to link FFMPEG's libraries (libavformat, libavcodec, etc) to my project.
I have downloaded as an example iFrameExtractor project, and have successfully build it.
xcode-proj opens fine and the sample app works fine, so I just took libs from this project to my one.
But xcode fails to build it, saying me
Undefined symbols for architecture armv7:
"av_register_all()", referenced from:
I checked target settings, and I cannot see any difference between my project's settings and iFrameExtractor.
I just moved all ffmpeg folder to my project's folder.
Notes:
1) nm commands tells me that this symbol is inside the library.
2) library is fat-file, including i386, armv6, armv7 architectures.
Please, help me, what am I doing wrong?
I just went through this yesterday :-)
In xcode, you need to add the .a file to the list of linked libraries in the project. The easiest way to do that is by dragging the .a directly onto the project entry in the navigation area on the left:
Alternatively, you can select them from the dialogs in the summary area of the project editor:
Just make sure you select the actual .a files, not the whole folder. Then, simply import their headers (as you are likely already doing...), and you should be good to go :-)

Resources