linkage_checker: ignore broken linkage with LLVM libc++.

[carlocab]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

When dyld is not able to find a library at its install name, it
attempts to find it inside its default search path.

This means that for libraries we ship that are also provided by the
system (e.g. libc++), brew linkage can fail even if the formula
still works (i.e. brew test succeeds).

Given this, it makes sense to attempt to dlopen the library first
before deciding the linkage is broken. This will be useful when we ship
Homebrew/homebrew-core#106925, which will move the install location of
libc++, causing brew linkage to fail for any formula that links with
that libc++.

Those formulae that link with LLVM's libc++ will fall back to Apple's
libc++, which is why we see multiple brew tests succeed even when
brew linkage failed in the LLVM PR linked above.

This change helps avoid unnecessary source rebuilds for formulae that
link with LLVM's libc++ after LLVM 15 ships.

[BrewTestBot]

Review period will end on 2022-09-12 at 04:52:28 UTC.

[carlocab]

This part is still necessary, since System Frameworks typically cannot be found by their basename.

[carlocab]

Doing this first does change the output of brew linkage slightly. System dylibs (e.g. libSystem.B.dylib) will typically be reported with only their basename, but system frameworks (e.g. CoreServices) need to be found via an absolute path so one will be reported.

This is probably more meaningful anyway, since these paths are no longer on-disk.

[BrewTestBot]

Review period ended.

[Bo98]

This makes sense for libc++ (if nothing was compiled with -D_LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS) but I'm less convinced it's desirable in the general case.

While yes dyld technically may work this way and the executable may "run", if something is (for example) linking to Homebrew curl but ends up using system curl, there could be problems later on and we will want to know about it, even if it's just for the automatic formula reinstall.

I would be ok special casing this for libc++ at the moment though, as long as we note down which formulae are affected by it.

[carlocab]

Yea, I initially started with a special case for libc++ and then wondered whether it should just be more general.

I'll switch it back.

[carlocab]

Scoped this to only LLVM libc++.

This will report no linkage with libc++ at all if linkage with LLVM's libc++ is broken. Ideally we probably want to report linkage with /usr/lib/libc++.1.dylib instead.

I'm punting on that since I'd like to get this in along with the tag for the Glibc fixes.

[Bo98]

Ideally we probably want to report linkage with /usr/lib/libc++.1.dylib instead.

In the long term, we'll phase out using LLVM's libc++ in our formulae.

[carlocab]

In the long term, we'll phase out using LLVM's libc++ in our formulae.

This should already be phased out in Homebrew/homebrew-core#106925. I'm just thinking of formulae in external taps that declare an LLVM dependency and inadvertently link with LLVM's libc++.