In some cases, we end up with several distinct DylibFiles that
have the same install name. Only emit a single LC_LOAD_DYLIB in
those cases.
This happens in 3 cases I know of:
- Some tbd files are symlinks. libpthread.tbd is a symlink against libSystem.tbd for example, so -lSystem -lpthread loads libSystem.tbd twice. We could (and maybe should) cache loaded dylibs by realpath() to catch this.
- Some tbd files are copies of each other. For example, CFNetwork.framework/CFNetwork.tbd and CFNetwork.framework/Versions/A/CFNetwork.tbd are two distinct copies of the same file. The former is found by -framework CFNetwork and the latter by the reexport in CoreServices.tbd. We could conceivably catch this by making -framework search look in Versions/Current instead of in the root, and/or by using a content hash to cache tbd files, but that's starting to sound complicated.
- Magic $ld$ symbol processing can change the install name of a dylib based on the target platform_version. Here, two truly distinct dylibs can have the same install name.
So we need this code to deal with (3) anyways. Might as well use
it for 1 and 2, at least for now :)
With this (and D103430), clang-format links in the same dylibs
when linked with lld and ld64.
nit: no need for llvm::