The project at hand is quite complex, and the link content is especially. I suddenly saw this warning again in recent days and wanted to inquire about when this deletion would be done, so that our team could make preparations and plan in advance.
-ld_classic or -ld64 About when will it be completely deleted?
Recommended
We’ve not shared any official word about the timeline here.
However, given that ld_prime [1] is now on its second major Xcode release, it’s definitely time to make the move.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] See An Apple Library Primer for an explanation as to why I still call it that (-:
Where should I step? It's not clear where to dig. Even Xcode 26.0 beta (17A5241e) this problem remains
Assertion failed: ((ct == Atom::ContentType::objcConst) || (ct == Atom::ContentType::objcData) || (ct == Atom::ContentType::constData) || (ct == Atom::ContentType::constText)), function ObjCClassReadOnlyDataRef, file Atom.cpp, line 3267.
We have the same problem.
XCode26b2 Linker assertion, then segfault 11 when build to device. For some unknown reasons, build to simulator works.
Previously, XCode16, we workaround with -ld_classic flag
Sorry I didn’t follow up earlier. I wasn’t notified of your response [1].
If the linker traps with an assert I recommend that you follow the advice I gave in this thread.
Please post your bug number here.
Reverting to ld64 is a reasonable short-term workaround, but you don’t want to rely on that in the medium-to-long term because it won’t be around forever. So it’s critical that you file bugs about the problems that you see.
Previously, XCode16, we workaround with -ld_classic flag
Did you file a bug about the issue at the time? If so, what was the bug number?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Partly that’s because they were in comments rather than replies. In general, it’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.