MacOs Big Sur list of missing libraries is wrong for copies or links to dynamic libraries

[Febbe]

As of change 62986286 in https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes. Links and Copies of dynamic libraries aren't located in the file system anymore, the lookup, if a dependency is available will fail, even if the library is existent and reachable over the cache:

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)

[kwin]

Thanks for the pointer @Febbe. Can you come up with a PR?

[Febbe]

Sorry, I don't even have enough time for my projects. We researched, why our app doesn't work smooth on Big Sur. While researching, we found out about this, and I created that issue, so you or someone else who has time can fix that.

[wkundrus]

I ran into the same issue on Monterey. Libraries are not found in /System/Library/Frameworks although they are there.

[wkundrus]

The point is, System framework binaries are now collected in the dylib cache. To remain useful, this project needs to be updated to read the binaries from the new location.

[kwin]

This requires some refactoring of MachOFile. The handle being returned by dlopen doesn't allow plain reads but only the higher level operation dlsym() (https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlsym.3.html#//apple_ref/doc/man/3/dlsym) which returns information about a specific symbol but not the full MachO headers.
Maybe an approach like this would work: https://stackoverflow.com/questions/20481058/find-pathname-from-dlopen-handle-on-osx but most probably the system libraries are just no longer macho files but merely existent in some cache, i.e. lack most of the information exposed by the tool.

[yergin]

Great tool! In my changes, InternalFile tries to load the library when it fails to open it. If loading succeeds, it's flagged as a "cached library" and this gets propagated to MachOModel which makes it show up as purple rather than displaying an error and have it come up missing:

I had a look at those approaches mentioned above, tried some of them out but I wasn't able to trace those cached libs to actual files on the system and I wasn't able get their dependencies. To be honest, it wouldn't be very useful to me even if I could because I'm not worried a system lib's dependency, they are always fine.

If you like this solution, I'd be happy to open a PR.