You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firebase C++ SDK: 13.12.0 (its macOS frameworks/darwin distribution wraps the underlying Firebase Apple SDK; "macOS SDKs are now built using Xcode 26.2" per the C++ SDK release notes starting around 13.8.0)
Xcode: 27.0 (27A266a)
clang: Apple clang version 21.0.0 (clang-2100.3.34.2)
ld: version 27037.1 (new/default linker)
macOS: 26.6.2 (build 25G83)
Architecture: arm64 (Apple Silicon)
MACOSX_DEPLOYMENT_TARGET: 15.7
Frameworks linked: firebase.framework, firebase_firestore.framework, firebase_auth.framework, firebase_analytics.framework, firebase_functions.framework, firebase_messaging.framework, firebase_remote_config.framework (the macOS desktop frameworks bundled by the Firebase C++ SDK, which wrap the Apple SDK)
What happens
Linking a macOS desktop app against firebase.framework + firebase_firestore.framework fails with a linker crash (not a normal "undefined symbol" error — the linker itself asserts and aborts):
It appears an Objective-C class reference is aliased across two separate framework binaries — one class-ref inside firebase_firestore.framework's error_apple.mm.o and one inside firebase.framework's locale_apple.mm.o — and the linker's new ClassRefToGotConverter pass hard-asserts instead of handling it.
What we've tried
-ld_classic — no longer has any effect on Xcode 27: ld: warning: -ld_classic is no longer supported and will be ignored. Same crash occurs anyway.
No special linker flags at all — same crash. This confirms it's not specific to -ld_classic; the default linker crashes on its own.
-Xlinker -dead_strip -Xlinker -allow_dead_duplicates (suggested as a workaround for a related issue in FirebaseAnalytics build error with -ld_classic, -ObjC and iOS 17.6 on Xcode 26 Beta firebase-ios-sdk#15284) — this does avoid the crash, but as a side effect the linker silently discards unrelated, legitimate symbols from other static libraries linked into the same binary (we saw Undefined symbol errors reappear afterward for FreeType, ICU, and other unrelated libraries), so it's not a safe workaround.
Expected behavior
The prebuilt macOS frameworks should link without crashing the linker, ideally without requiring -allow_dead_duplicates (which has known correctness risks per Apple's own linker docs).
Related issue
This looks closely related to firebase/firebase-ios-sdk#15284 (FirebaseAnalytics + -ld_classic on iOS), but reproduces here on macOS desktop with the default (non-classic) linker, so it isn't limited to -ld_classic usage.
Question for the Firebase team
Is this a duplicate/aliased symbol artifact from how firebase.framework and firebase_firestore.framework are packaged for macOS (e.g., the same translation unit/class getting folded into an alias across two separate framework binaries)? Has this been reproduced internally on Xcode 27, and is there a recommended workaround in the meantime (e.g. pinning to an older SDK release built with an earlier Xcode)?
Environment
frameworks/darwindistribution wraps the underlying Firebase Apple SDK; "macOS SDKs are now built using Xcode 26.2" per the C++ SDK release notes starting around 13.8.0)MACOSX_DEPLOYMENT_TARGET: 15.7firebase.framework,firebase_firestore.framework,firebase_auth.framework,firebase_analytics.framework,firebase_functions.framework,firebase_messaging.framework,firebase_remote_config.framework(the macOS desktop frameworks bundled by the Firebase C++ SDK, which wrap the Apple SDK)What happens
Linking a macOS desktop app against
firebase.framework+firebase_firestore.frameworkfails with a linker crash (not a normal "undefined symbol" error — the linker itself asserts and aborts):It appears an Objective-C class reference is aliased across two separate framework binaries — one class-ref inside
firebase_firestore.framework'serror_apple.mm.oand one insidefirebase.framework'slocale_apple.mm.o— and the linker's newClassRefToGotConverterpass hard-asserts instead of handling it.What we've tried
-ld_classic— no longer has any effect on Xcode 27:ld: warning: -ld_classic is no longer supported and will be ignored. Same crash occurs anyway.-ld_classic; the default linker crashes on its own.-Xlinker -dead_strip -Xlinker -allow_dead_duplicates(suggested as a workaround for a related issue in FirebaseAnalytics build error with -ld_classic, -ObjC and iOS 17.6 on Xcode 26 Beta firebase-ios-sdk#15284) — this does avoid the crash, but as a side effect the linker silently discards unrelated, legitimate symbols from other static libraries linked into the same binary (we sawUndefined symbolerrors reappear afterward for FreeType, ICU, and other unrelated libraries), so it's not a safe workaround.Expected behavior
The prebuilt macOS frameworks should link without crashing the linker, ideally without requiring
-allow_dead_duplicates(which has known correctness risks per Apple's own linker docs).Related issue
This looks closely related to firebase/firebase-ios-sdk#15284 (FirebaseAnalytics +
-ld_classicon iOS), but reproduces here on macOS desktop with the default (non-classic) linker, so it isn't limited to-ld_classicusage.Question for the Firebase team
Is this a duplicate/aliased symbol artifact from how
firebase.frameworkandfirebase_firestore.frameworkare packaged for macOS (e.g., the same translation unit/class getting folded into an alias across two separate framework binaries)? Has this been reproduced internally on Xcode 27, and is there a recommended workaround in the meantime (e.g. pinning to an older SDK release built with an earlier Xcode)?