Xcode 15 B/BL out of range Error During Build

Interesting.

Each CPU architecture has its own limits as to how far you can branch, but those limits should apply to both the old and new linker. Some questions:

• How big was this Mach-O previously? If it was previously huge, it’s possible that some small change in the linker just happened to push you over the edge.

• Have you enable the mergeable library feature, described in WWDC 2023 Session 10268 Meet mergeable libraries? Because it’s easy to see how that’d push you over the edge.

• You haven’t mistakenly enabled -no_branch_islands, have you? Branch islands are the standard way for the linker to get around the CPU architecture’s branch distance limit; disabling them can easily produce problems like this.

To fix this just add -ld64 to Other Linker Flags in Target.

That’s a temporary workaround, not a solution. As mentioned in the release notes, the old linker implementation will go away at some point. It’s important to investigate this now, because if it is a problem with the linker itself you want that fixed before the old implementation goes away.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We're building successfully with Xcode 14.3.1.

Additionally Xcode 15.0 is successful for simulator builds. Any iOS Device (arm64) or real device builds are failing with that error.

There is an entry on stackoverflow about flutter app, but mine is not a flutter app.

here

About questions;

• How can i measure Mach-O
• Enabled mergeable library but worked for error
• no_branch_islands is not modified, it is disabled.

Thanks

How can i measure Mach-O

You find links to various tools in An Apple Library Primer.

Enabled mergeable library but worked for error

I’m sorry but I don’t understand what you mean by this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry for missing word;

We've enabled mergeable library but "not" solved error

Our executable Mach-O file size is about 420 MB for ARM64 architecture. Is this a limit for new -ld_prime?

Our executable Mach-O file size is about 420 MB for ARM64 architecture.

That’s pretty big for a single Mach-O, but that’s kinda what branch islands are for (-:

Is this a limit for new -ld_prime?

I don’t know. But, given that this worked with -ld64, I’d say this error warrants a bug report. For hints and tips on tips on how to file an actionable bug here, see this post and the other posts on that thread.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Greetings,

I wanted to drop a reply here to say we're seeing a similar issue with our Unity (2022.3.11f1) builds. These builds were previously functional before our upgrade to macOS Sonoma and Xcode 15. Since the upgrade, we are now receiving the following:

ld: B/BL out of range 144489060 (max +/-128MB) to '__ZN3Geo8GeoArrayIPKN9Enlighten13MaterialGuids12InstanceInfoEE11SetCapacityEi'

It does appear that adding -ld64 to the Unity target and Framework target allows it to build.

We are concerned about the longevity of this workaround.

Best regards

We are concerned about the longevity of this workaround.

As you should be. I recommend that you file a bug about this. See this post for specific advice about how to file bugs related to ld_prime.

Please post your bug number, just for the record.

Oh, before you do that, make sure you test with the current Xcode 15.1 beta seed. It contains many fixes, although I’ve no specific info to suggest that it has a fix for this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We've fixed this issue with converting our dynamic frameworks to Swift Package Manager and also use SPM versions of CocoaPods library that support SPM. It is actually about dynamic_linking and static_linking issue that reaches limit of new linker ld_prime. As a result, we are statically linked our frameworks and issue is fixed. Hope it is helpfull for others.

Our Unity builds are still encountering this issue on Xcode 26. Our binary size is approximately 490 MB. I’d like to know whether there has been any progress on this issue.

ld: fixup error (kind=arm64_b26) at '_mFCC6D7100833D14F.island2' from branch-islands-file, B/BL out of range (displacement=180792912, max is +/-128MB), from 0x0FC7D740 to 0x1A8E8590 ('_mFCC6D7100833D14F')

I’d like to know whether there has been any progress on this issue.

There isn’t a simple answer to that. My experience with bugs like this is that the reported symptoms can have many underlying causes. So, if the developers above had created bug reports (not sure if they did) and then posted those bug numbers (which they didn’t)-: I would be able to check on the state of those bugs. However, there’s no guarantee that the fixes for those bugs would help with your issue.

So, my advice here is:

1. Test with the latest released version of Xcode 26, just to make sure it’s not fixed already.
2. If not, file a bug.
3. Do you best to make it actionable, per the advice in this post.
4. Reply here with the bug number, for the benefit Future Developers™ who stumble across this thread.
5. Then go hunting for workarounds.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"