macdylibbundler
macdylibbundler copied to clipboard
Any way to not ignore system libs?
Hello! Was very excited to find this tool, as it seems like a great replacement for my own brittle, ad-hoc, app-specific script.
Unfortunately, an issue I've recently encountered is that I've had many users report that my app (Tad ) doesn't work on macOS 11 because I built it on macOS 12, and apparently libc++.1.dylib
on macOS 11 isn't compatible.
The only robust solution I can think of is to bundle libc++ with my app, and do the appropriate fixups.
Unfortunately, as far as I can tell, there is currently no way to bundle libc++ and do the fixups with macdylibbundler since libc++ is found in /usr/lib/libc++.1.dylib
, and it doesn't look like there's a way to disable the check for isSystemLibrary
. Is that a correct interpretation, or am I missing something? Any suggestions much appreciated. Would you consider a PR for adding a command line argument to disable the isSystemLibrary
check (or perhaps exclude specific libs from the check)?
Hi, I have very little time to spend on dylibbundler myself, however pull requests are always welcome so long that they are well-tested to avoid breaking stuff
Thanks for the followup, @mg186 . Alas, after further investigation, it turns out that this doesn't even appear possible to bundle libs like /usr/lib/libc++.1.dylib
, because, as of Big Sur, the file for this doesn't actually exist in the filesystem, it's handled by the linker cache! From an Apple Developer Forum post:
New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)
So I'm going to give up on using macdyllibbundler
to try and address the problem, and just live with doing separate builds on macOS 11 and macOS 12, and shipping separate binaries. (Or possibly just shipping the macOS 11 binary if it runs on macOS 12).
Feel free to close this issue.
So I'm going to give up on using
macdyllibbundler
to try and address the problem, and just live with doing separate builds on macOS 11 and macOS 12, and shipping separate binaries. (Or possibly just shipping the macOS 11 binary if it runs on macOS 12
You should be fine with targeting macOS 11 (or even older, depending on needed frameworks/features) as per Apple, "each release of macOS strives to be binary compatible with applications built using [older SDKs]"(https://developer.apple.com/library/archive/technotes/tn2456/_index.html).