Switch from `objdump` to dlopen on macOS BS to detect nested dependencies

[helje5]

macOS BS has the "dyld shared cache" which breaks running objdump on the dependencies. E.g. this results in BS Safari not having any features detected.

$ otool -L /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari (architecture x86_64):
	/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
/Applications/Safari.app/Contents/MacOS/Safari (architecture arm64e):
	/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)

W/ the "dyld shared cache", the /System/Library/PrivateFrameworks/Safari.framework doesn't actually exist on disk anymore (hence objdump can't analyse it).

Maybe we can use dlopen to load and open an executable and then somehow traverse the link list (w/o actually executing the binary)?

[saagarjha]

Alternatively, you could dump the shared cache and save the link graph, as I expect this to only be a problem if an app links a system framework that transitively links AppKit.

Alternatively you can just launch the app, stop it, and see what's loaded into the process.

[helje5]

Alternatively, you could dump the shared cache and save the link graph

How would I do this?

[saagarjha]

You can use something like https://github.com/saagarjha/dyld-shared-cache-big-sur to grab all the files and they read the dependencies from everything.