Hello Quinn, I'm reviving this slightly old thread. Your explanation of the dynamic library cache and its history in this thread has been very useful. I have a few related questions. You note: So in recent Xcode releases we’ve replaced the libraries in your SDKs with stub libraries [2]. That is, there’s no longer a libpcap.dylib library in the SDK, but rather a much smaller libpcap.tbd stub library [3]. It’s a text file (.tbd stands for text based description) so feel free to open it up and take a look. Consider one such .tbd file that's shipped in macOS M1 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/AppKit.tbd. This file doesn't contain the dynamic libraries that this library depends on. Is that intentionally left out? Tools like otool would be able to use that info to list the dependencies of the library if that info was present, isn't it? You noted: Given the above reality, the libraries in /usr/lib are no longer needed: ... This is fine if you’re using Xcode, or Apple’s command-line tools, because they know how to look inside an SDK for headers and stub libraries. Is otool considered one of Apple's command line tools? The output of man otool does seem to suggest that it is one. If so, then do you think enhancing otool to seamlessly (or via a new option) look into the dynamic library cache if a path specified to that tool doesn't exist on the filesystem would be a valid enhancement? I ask these questions in context of https://developer.apple.com/forums/thread/705281 where I ended up having to use external tools to extract the cache to get hold of the information I was after. Finally, is there a doc/schema which explains the structure/contents of .tbd files. For example, I see that each of these file contents end with ... which at first looked odd to me and made me check if the rest of the contents in that file was missing.

I didn't find a way to get this working with otool. Nor could I find a tool which would seamlessly work against dependency paths of the system libraries which don't represent a file system path but instead are in within the dynamic library cache. However, I did find a workaround. I found this useful tool https://github.com/keith/dyld-shared-cache-extractor which extracts the dynamic cache library to a directory. The dynamic library cache is available on the filesystem as a file under /System/Library/dyld/ directory. For example, /System/Library/dyld/dyld_shared_cache_arm64e. So you can pass that file as an argument to the tool to extract the contents. Once you extract the cache, you can then use otool to list the dependencies of the system library of your choice, as usual. Do note though that the extracted content is around 2.7 GB.

Thank you very much for replying. I had a quick look at your bug and it’s definitely landed in the right place. I will wait to hear back there, then. One small related question - are changes like these (at this low level of the OS) documented some place in the releases? This is more for future reference so that we can take a look at them before filing any issues.

I found some snippet in an unrelated forum/question where someone had shown how to find the compiler flags at runtime that were passed to zlib. This is a zlib specific API and looks something like: zlibCompileFlags(); The API is here https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L1174. This can then be combined with flags of your choice (the flags are noted in the doc of that API). So in my case I added something like: printf("compiler flags %lu\n", zlibCompileFlags()); if ((zlibCompileFlags() & (1 << 9))) { printf("Compiled with ASMV or ASMINF, uses ASM code\n"); } else { printf("No ASM code\n"); } if ((zlibCompileFlags() & (1 << 8))) { printf("Compiled with ZLIB_DEBUG\n"); } else { printf("No ZLIB_DEBUG\n"); } if ((zlibCompileFlags() & (1 << 10))) { printf("Compiled with ZLIB_WINAPI\n"); } else { printf("No ZLIB_WINAPI\n"); } to verify the flags of my interest. The output of that code against MacOS 12.2.1 shows that the ZLIB_DEBUG wasn't enabled while building this library. So essentially, I won't be seeing any logging output from this library at runtime. Having said that, this is a very "intrusive" way since I had to write some C code and link it against this zlib library to invoke this API and get the output. It would help if there was a way to just know what set of commands and options were used to build this zlib library that's shipped in MacOS. Anyone has any ideas?