dyld 512 dylibs limit

Question

Created Jun ’22

Replies 3

Boosts 0

Participants 2

I work for MongoDB and our app builds many dylibs. Recently we have reached a number of dylibs which is causing problems. Apparently no more than 512 dylibs are allowed to be loaded. I can not find any documentation on this. I found in the old source code a reference to this: https://opensource.apple.com/source/dyld/dyld-852.2/src/ImageLoader.cpp.auto.html

if ( libCount > 512 ) dyld::throwf("too many dependent dylibs in %s", path);

Does anyone know why this is and what versions of OSX (or dyld) have this limitation? Where is this documented?

Answered by DTS Engineer in 717542022

Does anyone know why this is

The dynamic linker has a long and complex history and it’s not unusal to encounter limitations like this. I expect the person who wrote that code thought “Why would anyone need more than this?”

what versions of OSX (or dyld) have this limitation?

That version of the code corresponds (roughly) to macOS 11. The dynamic linker in macOS 12 does not have this limit. Looking backwards, I see the same check in macOS 10.14, which is as far back as I care to check.

Where is this documented?

AFAIK it’s not.

Having said that, this is way too many dependencies. Every one is costing you in terms of memory and load time. I strongly encourage you to merge some of these libraries.

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

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’22

Accepted Answer

Does anyone know why this is

The dynamic linker has a long and complex history and it’s not unusal to encounter limitations like this. I expect the person who wrote that code thought “Why would anyone need more than this?”

what versions of OSX (or dyld) have this limitation?

That version of the code corresponds (roughly) to macOS 11. The dynamic linker in macOS 12 does not have this limit. Looking backwards, I see the same check in macOS 10.14, which is as far back as I care to check.

Where is this documented?

AFAIK it’s not.

Having said that, this is way too many dependencies. Every one is costing you in terms of memory and load time. I strongly encourage you to merge some of these libraries.

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

0

Answer 2

dmoody256 OP

Jun ’22

Thanks for the info! I agree we have too many shared libraries and have plans to consolidate, however other platforms there is marginal or insignificant start up time impact.

0

Answer 3

DTS Engineer OP

Apple

Jun ’22

I agree we have too many shared libraries and have plans to consolidate

Cool. Note that there is a build- vs run-time trade-off here. The linker team gave a presentation on that topic at WWDC this year, namely WWDC 2022 Session 110362 Link fast: Improve build and launch times. It’s good stuff!

There’s also a couple of historical WWDC videos on this topic:

WWDC 2016 Session 406 Optimizing App Startup Time

WWDC 2017 Session 413 App Startup Time: Past, Present, and Future

These videos are no longer available from Apple [1] but if you rummage around on the ’net you may find relevant info from them.

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

[1] Don’t ask me why or I’ll start to whimper.

0