Undefined symbol: type metadata for Swift._StringObject.Variant

While trying to build our project with Xcode 12 I ran into multiple build failures while rebuilding our dependencies with Carthage.

I always end up getting this linker error:


Undefined symbols for architecture armv7: "type metadata for Swift.StringObject.Variant", referenced from: outlined init with take of Swift.StringObject.Variant in CountryCodePickerViewController.o ld: symbol(s) not found for architecture armv7

This happened for me for both Alamofire and PhonenumerKit; therefore, this looks like an issue with the new Xcode and not the frameworks themselves. Archiving them with Xcode 11 works without a problem.

As an intermediate workaround I removed the armv7 architecture from the valid architectures.


Replies

I also filed the following feedback: FB7754126
Can you configure the deployment targets that Carthage builds dependencies with?

I'm using CocoaPods and had the same problem. For me, the solution was to delete the deployment target settings for all the pod targets (most of which were iOS 9, etc) so they'd fallback to the values I have set in my configurations, which are higher (iOS 12, macOS 10.13, etc).
As far as I can see, the deployment targets are defined in the respective project files so we cannot change them easily.
I encountered the same error archiving Split.io's framework with Xcode 12 b1 and filed FB7757707 about the issue.
I'm also seeing this issue, but for me I suspect it's related to the fact a 'release' iOS and watchOS Simulator builds i386 and x86_64 'Strip' phase output the following error:

ld: warning: building for iOS, but linking in object file (/tmp/strip.RgFyCE) built for iOS Simulator

Then when linking I get the 'type metadata for Swift.StringObject.Variant' error.

Neither the Strip warnings or linking error occur when doing a 'debug' build (because Strip doesn't get called in debug builds).

Feedback: #FB7750733
To all experiencing this issue: It is possible that Carthage is reusing build products from a different Xcode version that may contain symbols that are no longer present in a newer Swift version. Unless these libraries are built with library evolution enabled, you will need to ensure that the Xcode used to build your dependencies matches the Xcode that was used to build your apps and frameworks. In this case, please try selecting Xcode 12 with xcode-select, clearing any build products cached by Carthage, and rebuilding the entire stack with the tools in the new Xcode.

If the issue persists, please continue to file feedback.
For my error #FB7750733 this is completely fresh build of my own library with Xcode 12, I don't use carthage or cocoapods.
I encountered the same issue.
I cannot archive my dynamic library on Xcode 12 with the same error message.
But Xcode 11.5 works fine.x

Lottie-iOS has the same error and resolve it with a work around.
https://github.com/airbnb/lottie-ios/issues/1214
Finally, I solved it by casting String as follows.

Code Block swift
🙅‍♂️ textLabel.text = someTitle
🙆‍♂️ textLabel.text = someTitle as String

Code Block swift
🙅‍♂️ someTitle.isEmpty
🙆‍♂️ (someTitle as String) == ""

We also see this issue on clean fresh archives both from Carthage and also directly from Xcode.
Thanks for all the info and for filing feedback on this, everyone. This looks like an Xcode problem and we're investigating. For now, the simplest workaround would be to disable building for iOS 32-bit, as it looks like the problem only affects that slice.
I dont see any actual file warnings except for the build error. So it's hard to say which line it occurred on.

Does anyone else see actual line numbers this occurs on?
I am experiencing the same issue on Xcode 12 Beta 1 with Cocoapods.
mikeash_ says:

Thanks for all the info and for filing feedback on this, everyone. This looks like an Xcode problem and we're investigating. For now, the simplest workaround would be to disable building for iOS 32-bit, as it looks like the problem only affects that slice.

To flesh this out a bit, in the build settings of your project, go to "Architectures -> Valid Architectures". For iOS, if you see a bunch of ARM architectures in this field, remove any armv7... ones leaving only arm64.

If no ARM architectures are specified in this field, Xcode will try to build all of them by default, so add a lone arm64 to prevent this.

(For mac builds, by the way, you'll want to do the same thing except make sure you remove any i386 entries and have a single x86_64 in there.)

And make sure you make all these changes in some temporary, easily reversible way! This is not a best practice, but rather a work-around until this gets fixed — hopefully in a future beta release?