This article explores how apps link differently against the runtime depending on the deployment target.
How can you link against the same dylib, which has a single install name, but any linked binaries record different dylib install names?
ld64sources are published by Apple, so we can see how the linker actually works. The code can be found in macho_dylib_file.cpp inside the method
File::addSymbol(). It defines the magic format as
$ld$ $ $.
$ld$magic symbols are used heavily by Apple’s system frameworks to maintain backwards compatibility while moving symbols between frameworks. If you look at the various .tbd files in the Xcode SDKs you’ll see all sorts of shenanigans along these lines.
NSObjectmoved from CoreFoundation to libobjc in macOS 10.8. libobjc has
$ld$hidesymbols for old OS versions (“
NSObjectis here, but it used to be somewhere else”). CF has
$ld$addsymbols for old OS versions (“
NSObjectis elsewhere, but it used to be here”).