Perhaps this topic would be more relevant on SO, but the circumstances in which I get the issue may make it relevant in the Swift forum.
I have a sample project in which I play with all kinds of goodness of SwiftUI, property wrappers, Firebase and combining all these things.
I wanted to try out the latest master toolchain snapshot (from Oct. 10th) on this project, and got a linker error.
The linker error is with a third party framework written in Objective-C.
The error is:
Undefined symbols for architecture x86_64:
"___isOSVersionAtLeast", referenced from:
_FIRInstanceIDCurrentLocale in FirebaseInstanceID(FIRInstanceIDUtilities.o)
ld: symbol(s) not found for architecture x86_64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
The reason I am posting in the Swift forums is that I do not get this linker error using the toolchain that comes with Xcode 11.1.
So I am guessing that the missing symbol is something that the compiler injects?
From what I could gather on Stack Overflow, the reference to the symbol comes whenever a framework uses availability macros.
So my questions are:
What is this symbol?
Where is it supposed to originate from?
Is it expected that there is a linker error using the latest snapshot toolchain, while the linker error is not occurring when I build with the Xcode 11.1 toolchain?
Are there any workarounds that I could apply.
This symbol is runtime support for platform version checking. It is vended by CompilerRT's builtins, which on macOS is re-exported through libSystem. I believe this is a bug in Apple's system.
This indicates the desired symbol is missing in the system image, and as a result, in the TBDs in the SDK content. Both linking to System as a framework and linking against it as a library will not yield the desired symbol.
If you are setting your minimum deployment version higher than whatever value you are using for the checked API, the compiler should be able to fold away the check.
The workaround may not be viable: bump your minimum deployment version to the newest API that you are using. In this case, you would need to bump that and then rebuild Firebase.
Thanks so much for replying!
So do you think it would be correct of me to create a radar (or feedback) - or rather a bug on bugs.swift.org?
From what I understand I would guess the former.
Thanks again!
The ___isOSVersionAtLeast symbol is not vended by libSystem, it's vended by the compiler-rt builtin archives provided by the toolchain. There's no bug in libSystem here.
It looks like the toolchain has the right symbol for macOS:
swift-DEVELOPMENT-SNAPSHOT-2019-10-10-a.xctoolchain/usr/lib/clang/7.0.0/lib/darwin/libclang_rt.osx.a:os_version_check.c.o: 0000000000000000 T ___isOSVersionAtLeast
Are you building your project for macOS? If yes, can you paste the linker invocation that you get by re-running the clang command that called the linker (it should be the one that failed in your Xcode build logs) with -v to see what happened.
It is not directly vended by libSystem, but libSystem does re-export compiler-rt. Or is that not supposed to be re-exported? Yes, adding a static copy of the compiler-rt would also work (the linker will defer to the local definition over the shared version from libSystem's re-exported dylib).
Hi Alex,
I am building for the iOS simulator, so I don't know if that counts for building for macOS?
Anyways, here is the linker command and output when I run it with -v:
The toolchain from Swift.org doesn't have a static archive for the iOS simulator, so that explains why you're getting the error. I'm not 100% sure why the Swift toolchain doesn't build compiler-rt for the iOS simulator though. @mishal_shah do you have any idea why?
Hi @Alex_L,
Thanks for your reply - I get the same issue when building for an actual iOS device.
Can you determine whether this is a case of 'works as intended'? Or should I perhaps file a bug for the issue?
Hi @Mike_Ash,
The linker issue still appears with the master branch toolchain from November 1st.
It happens for both the iOS simulator and when building for iOS.
Here is the debug output from when I try linking on the simulator:
Undefined symbols for architecture x86_64:
"___isOSVersionAtLeast", referenced from:
_FIRInstanceIDCurrentLocale in FirebaseInstanceID(FIRInstanceIDUtilities.o)
ld: symbol(s) not found for architecture x86_64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
Is there any other information I can provide to help?
@Morten_Bek_Ditlevsen I am also experiencing this issue. Using Xcode Version 11.2 (11B52), and attempting to build for simulator with either Toolchain: Swift 5.1 Release 2019-09-19 (a) or Toolchain: Swift 5.1.1 Release 2019-10-11 (a), I receive the below error during linker invocation.
This issue does not occur when using the Swift 5.1.2 compiler included in Xcode 11.2
Looks like we are using the same Objective-C Library as well
Undefined symbols for architecture arm64:
"___isOSVersionAtLeast", referenced from:
-[CCTUIKitAXUtils initPrivate] in FirebasePerformance(CCTUIKitAXUtils_911abdd4bc813e022ac3a52c1f0261af.o)
-[CCTUIKitAXUtils isAssistiveTouchRunning] in FirebasePerformance(CCTUIKitAXUtils_911abdd4bc813e022ac3a52c1f0261af.o)
-[CCTUIKitAXUtils isShakeToUndoEnabled] in FirebasePerformance(CCTUIKitAXUtils_911abdd4bc813e022ac3a52c1f0261af.o)
-[CCTUIKitAXUtils updateAccessibilityStateCache] in FirebasePerformance(CCTUIKitAXUtils_911abdd4bc813e022ac3a52c1f0261af.o)
-[APMMeasurement sendDeepLinkURLToAppDelegateOnMainThread:extraInfo:] in GoogleAppMeasurement(APMMeasurement_77d66481554a3daf14fde66dd9edd8c4.o)
-[APMSqliteStore prepareSQL:error:] in GoogleAppMeasurement(APMSqliteStore_0ed784bc5f04451d45128745e2fe2383.o)
-[GDTApplication init] in GoogleDataTransport(GDTPlatform.o)
...
ld: symbol(s) not found for architecture arm64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
Thank you so much for the work-around, @Mike_Ash !
It works like a charm - and now I have some really fun code running using property wrapper composition which I have been toying with since the first glimpse of the possibility of composing property wrappers. Yay!
