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 archit
'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.
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"
This seems to be caused (for most) by linking a third-party library that does not support the requested architecture.
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.
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 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?