4 ms·
Many, perhaps most?, dylibs that a Mac app ships with are all within the app bundle itself, and signed as such, so dylib sharing is not a common use case.
by compiler-guy 3y ago
Many, perhaps most?, dylibs that a Mac app ships with are all within the app bundle itself, and signed as such, so dylib sharing is not a common use case.
- liuliu 3y agoYeah, and the only reason they don't static link is because these dylibs are some 3rd-party closed-source libraries to avoid a lot of version clashes comparing to ship static lib naively. Otherwise you put some code in dylib so your app extension can share some code with the main app, but that is tricky due to different RAM usage restrictions between app extension v.s. main app.
- remram 3y agoRAM usage restrictions?
- liuliu 3y agoFor example: https://tailscale.com/blog/go-linker/ https://tailscale.com/blog/go-linker/ talks about how they slim down the Go runtime to workaround the 15MiB memory limit for network extension.
- remram 3y agoBut what does that have to do with dylibs? If you have RAM usage restrictions, aren't they for the whole process, so the main binary and all its dylibs?
- liuliu 3y agoYeah, I am not explaining myself very well. I meant: people try to sharing code between main app and extensions with dylib. If they don't do that, they have code-duplication in the app bundle so the binary size is main code + 2 * shared code + extension code. However, it becomes more complicated because if you just naively sharing the code, your sharing part will be bloated, therefore, making the RAM usage higher than a static linked one (because static linked sharing code can do dead-code elimination better).