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

[Mark Rowe via llvm-commits]

Daniel =?utf-8?q?Rodríguez_Troitiño?Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/97639 at github.com>


bdash wrote:

Apple's linker rejects linking to libraries with allowable client lists:

```
$ cc -framework vecLib -o test test.m         
ld: cannot link directly with 'vecLib' because product being built is not an allowed client of it
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

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:
```
$ cc -framework vecLib -fuse-ld=lld -Bllvm-build/Release+Asserts/bin -o test test.m
$ nm -m test | grep vecLib                                                                                               
                 (undefined) external _vvdiv (from vecLib)
$ grep ' clients:' $(xcrun --show-sdk-path)/System/Library/Frameworks/Accelerate.framework/Versions/Current/Frameworks/vecLib.framework/vecLib.tbd
    clients:         [ Accelerate ]
    clients:         [ vecLib ]
    clients:         [ vecLib ]
    clients:         [ vecLib ]
    clients:         [ vecLib ]
    clients:         [ Sparse, vecLib ]
```

What was the motivation for this change? Generating binaries that don't respect the allowable client list means applications will break if / when Apple moves symbols between libraries. Is this intentional?

There's no bug associated with this change so I cannot tell what problem it is trying to solve.

test.m:
```
#include <stdio.h>
#include <vecLib/vForce.h>

int main(int argc, char**argv) {
    fprintf(stderr, "%p\n", &vvdiv);
    return 0;
}
```


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