Missing librairies in /usr/lib on Big Sur?

To solve a dependency tangle on an app, I’m trying to write a simple command line tool that would display all the dependencies of a given app or library, and output it in a format suitable for post-processing by graphviz. The idea here is to collect and lay out the output of the otool -L utility, recursively called on all the dependencies of the target app/lib.

Unfortunately, when I try otool -L with, say, otool itself, I get this:

Code Block shell
Dev > otool -L /usr/bin/otool
/usr/bin/otool:
/usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)

Fine. But now:

Code Block shell
otool -L /usr/lib/libxcselect.dylib
/Library/Developer/CommandLineTools/usr/bin/objdump: error: '/usr/lib/libxcselect.dylib': No such file or directory

Oops. Indeed, /usr/lib seems mostly empty, and most of what lies inside are links on missing (I assume: invisible) libs.

So my question is: where are all the libs gone, and it is possible to bring them back to the surface?
Post not yet marked as solved Up vote post of Vingt-Cent Down vote post of Vingt-Cent
23k views

Replies

# not good.
sa = util.find_library('System')
sb = framework_find('System')
sc = framework_find('System.framework')

ga = util.find_library('OpenGL')
gb = framework_find('OpenGL')
gc = framework_find('OpenGL.framework')

I'm not an expert in this area and new to this, but are you sure these frameworks are expected to be there in the cache at all? For example, when I extract the dyld cache and look into its contents I don't see any of these frameworks. Neither System.framework nor OpenGL.framework. In fact I don't even see Python.framework in that cache. So your "good" case - is it likely that when Python was installed that it actually installed this framework on the filesystem and your calls to util.find_library('Python') and framework_find('Python') are actually finding it on the filesystem and not from the cache?

Finally, is there a doc/schema which explains the structure/contents of .tbd files.

Not that I’m aware of. I agree there there should be and I’d appreciate you filing a bug requesting that. Please post your bug number, just for the record.

I have filed FB10013233 requesting documentation for these files.

Add a Comment

I am getting this error trying to compile AI-Feynman

ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd' for architecture x86_64

I tried to generate a new .tbd file from libSystem.dylib with 'tapi stubify ...' but I can't locate the libSystem.B.dylib file. The other .dylibs in XCode are not the right ones.

% locate libSystem.B.dylib                 
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libSystem.B.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/watchOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libSystem.B.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libSystem.B.dylib

Any ideas on how to generate a replacement .tbd file from a 'virtual' shared library which lives in a cache?

% otool -L /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libSystem.dylib    

/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libSystem.dylib (architecture x86_64):
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 85.0.0)
	/usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 60191.100.1)
	/usr/lib/system/libcompiler_rt.dylib (compatibility version 1.0.0, current version 103.1.0)
	/usr/lib/system/libcopyfile.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libcorecrypto.dylib (compatibility version 1.0.0, current version 1218.100.47)
	/usr/lib/system/libdispatch.dylib (compatibility version 1.0.0, current version 1325.100.36)
	/usr/lib/system/libdyld.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libmacho.dylib (compatibility version 1.0.0, current version 994.0.0)
	/usr/lib/system/libremovefile.dylib (compatibility version 1.0.0, current version 60.0.0)
	/usr/lib/system/libsystem_asl.dylib (compatibility version 1.0.0, current version 392.100.2)
	/usr/lib/system/libsystem_blocks.dylib (compatibility version 1.0.0, current version 79.1.0)
	/usr/lib/system/libsystem_c.dylib (compatibility version 1.0.0, current version 1507.100.9)
	/usr/lib/system/libsystem_collections.dylib (compatibility version 1.0.0, current version 1507.100.9)
	/usr/lib/system/libsystem_configuration.dylib (compatibility version 1.0.0, current version 1163.100.19)
	/usr/lib/system/libsystem_containermanager.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_coreservices.dylib (compatibility version 1.0.0, current version 133.0.0)
	/usr/lib/system/libsystem_darwin.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_dnssd.dylib (compatibility version 1.0.0, current version 1557.103.1)
	/usr/lib/system/libsystem_featureflags.dylib (compatibility version 1.0.0, current version 56.0.0)
	/usr/lib/system/libsystem_info.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_m.dylib (compatibility version 1.0.0, current version 3204.80.2)
	/usr/lib/system/libsystem_malloc.dylib (compatibility version 1.0.0, current version 374.100.5)
	/usr/lib/system/libsystem_networkextension.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/system/libsystem_notify.dylib (compatibility version 1.0.0, current version 301.0.0)
	/usr/lib/system/libsystem_product_info_filter.dylib (compatibility version 1.0.0, current version 10.0.0)
	/usr/lib/system/libsystem_sandbox.dylib (compatibility version 1.0.0, current version 1657.103.1)
	/usr/lib/system/libsystem_sim_kernel.dylib (compatibility version 1.0.0, current version 238.100.1)
	/usr/lib/system/libsystem_sim_platform.dylib (compatibility version 1.0.0, current version 238.100.1)
	/usr/lib/system/libsystem_sim_pthread.dylib (compatibility version 1.0.0, current version 238.100.1)
	/usr/lib/system/libsystem_trace.dylib (compatibility version 1.0.0, current version 1375.100.9)
	/usr/lib/system/libunwind.dylib (compatibility version 1.0.0, current version 202.2.0)
...

(base) davidlaxer@x86_64-apple-darwin13 iot-inspector-client % ls -l /usr/lib/system
total 1720
drwxr-xr-x  4 root  wheel      128 May  9 14:30 introspection
-rwxr-xr-x  1 root  wheel  1617536 May  9 14:30 libsystem_kernel.dylib
-rwxr-xr-x  1 root  wheel   512560 May  9 14:30 libsystem_platform.dylib
-rwxr-xr-x  1 root  wheel   656656 May  9 14:30 libsystem_pthread.dylib
-rwxr-xr-x  1 root  wheel   150080 May  9 14:30 wordexp-helper

Any ideas on what the linker doesn't like about file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd' for architecture x86_64

The problem as caused by version 12.0.0 of ld which lived in my Anaconda virtual environment. ld 13.1.6 did not have the issue.

% ld -v
@(#)PROGRAM:ld  PROJECT:ld64-764
BUILD 11:29:01 May 17 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)