extend/ENV/super: avoid adding llvm to HOMEBREW_LIBRARY_PATHS

[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?

---

This leads to undesired linkage with LLVM's libunwind (because it
shadows the system's libunwind).

See, for example, Homebrew/homebrew-core#169354.

[Bo98]

Does this still work OK for things that link to libLLVM/libclang?

[carlocab]

Does this still work OK for things that link to libLLVM/libclang?

Haven't tested, but I'd be shocked if it didn't for nearly all of them, since they usually use flags from a CMake config file (or from llvm-config). Will test a bit.

[Bo98]

Makes sense yeah

[carlocab]

Yea, seems to not break things (tried castxml and nvc). But perhaps it doesn't go far enough -- maybe what we want to do is set LIBUNWIND_INSTALL_LIBRARY_DIR to something like lib/"unwind" (or perhaps lib/"system", in analogy to Apple's /usr/lib/system/libunwind.dylib) to make sure we're not linking to it unless we really mean to.

[Bo98]

I agree. You should only use LLVM libunwind if you absolutely need it - not by default. Like how we did with libc++, which might itself be something that uses LLVM libunwind.

[carlocab]

Cool. Let's do that. At that stage, though, it makes me wonder if LLVM needs to be keg-only anymore. (All remaining libs in the lib directory don't shadow something OS-provided, IIRC)

[Bo98]

it makes me wonder if LLVM needs to be keg-only anymore

The executables will shadow system clang which we don't want.

[scpeters]

I just tested this pull request and can confirm that it avoids unintended linkage with libunwind for formulae in my 3rd-party tap and will resolve osrf/homebrew-simulation#2639 once I rebuild the bottles after this is merged.

Please let me know if there's any further testing I can assist with.

[MikeMcQuaid]

Thanks @carlocab! I think it's worth undrafting and merging as-is given it fixes some cases and we can always iterate on a better fix later.