[lld] [lld] Do not implicitly link non "public" libraries (PR #97639)

[Daniel Rodríguez Troitiño via llvm-commits]

drodriguez wrote:

> What was the motivation for this change?

The motivation is more or less replicated on the test. With the Xcode 16 SDKs there's a new "private" framework that does not exist in previous SDKs, but it was reexported from the "public" framework that existed in previous versions. The code in `isImplicitlyLinked` used to consider the libraries in `/usr/lib` and `/System/Library/Frameworks` linkable. The new "private" framework lives in one of those paths, so it was a candidate to be implicitly linked, with the bad luck that previous versions of the OS will not find the new file and fail to start the binaries. With the new code, libraries are only implicitly linked if the libraries do not have "allowable clients", which is the case in the new SDKs. Libraries with "allowable clients" should had never been linked directly, anyway.

> After this change, not only does lld not reject linking to vecLib.framework, it links to the library despite the binary not being an allowed client:

This was true *before* and *after* this change. LLD does not honor "allowable clients" at all. If you explicitly link against a private library, LLD will do what you ask. The changes above was trying to avoid a implicit link, but it was not trying to avoid any explicit link the user tries to do in the command line. I think nobody has taken the time to implement all the system of alloweable clients into LLD. It is of limited value to anybody that do not develop SDKs, which in the case of macOS, it is just Apple, and they use their own linker.

What this change was doing was that when linking to `Accelerate` (an allowable client of `vecLib`), `vecLib` will not be linked directly, but `Accelerate` will. Before this change, depending on the symbols, `vecLib` might have been linked incorrectly.

https://github.com/llvm/llvm-project/pull/97639