Undefined symbol: type metadata for Swift._StringObject.Variant

Question

Created Jun ’20

Replies 27

Boosts 0

Views 15k

Participants 20

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.

Boost

Answer 1

franzb OP

Jun ’20

I also filed the following feedback: FB7754126

0

Answer 2

tundaware OP

Jun ’20

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).

0

Answer 3

franzb OP

Jun ’20

As far as I can see, the deployment targets are defined in the respective project files so we cannot change them easily.

0

Answer 4

jibane200 OP

Jun ’20

I encountered the same error archiving Split.io's framework with Xcode 12 b1 and filed FB7757707 about the issue.

0

Answer 5

electricbolt OP

Jun ’20

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

1

Answer 6

Engineer OP

Apple

Jun ’20

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.

0

Answer 7

electricbolt OP

Jun ’20

For my error #FB7750733 this is completely fresh build of my own library with Xcode 12, I don't use carthage or cocoapods.

0

Answer 8

kahayash OP

Jun ’20

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

0

Answer 9

kahayash OP

Jun ’20

Lottie-iOS has the same error and resolve it with a work around.
https://github.com/airbnb/lottie-ios/issues/1214

1

Answer 10

kahayash OP

Jun ’20

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) == ""

2

Answer 11

franzb OP

Jun ’20

We also see this issue on clean fresh archives both from Carthage and also directly from Xcode.

0

Answer 12

Developer Tools Engineer OP

Apple

Jun ’20

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.

13

Answer 13

mikeKane OP

Jun ’20

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?

0

Answer 14

adincebicKlika OP

Jun ’20

I am experiencing the same issue on Xcode 12 Beta 1 with Cocoapods.

2

Answer 15

jemmons OP

Jun ’20

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?

2