We generally don't downgrade, but prefer to ship a further patch to fix issues (possibly after they've been investigated upstream). It's not clear to me what the issue is, whether it's been investigated, how it manifests. Can you explain?

@fxcoudert the more detailed story can be found in https://discourse.brew.sh/t/llvm-config-10-0-1-advertise-libxml2-tbd-as-system-libs/8593

With the 10.0.1_0 update on #58450 $ llvm-config --system-libs started listing -llibxml2.tbd, which is not a valid library.

With #61005 I attempt backporting some changes in llvm master to 10.x release branch. That worked fine for me and to other only if the formula is built from source. The bottles for 10.0.1_1 are still showing -llibxml2.tbd instead of -lxml2 as they should.

Despite that the backported patch received some feedback from llvm, I am unable to understand the difference between my environment and the CI. So whatever attempt that will work on my machine it will uncertain it will lead to something that works in the CI.

Also, this will probably affect 11.0.0.

We are not going to revert based on a problem that doesn't seem to impact many people, which depends on the local configuration, and the root cause of which is not understood.

Has the bug been reported to LLVM?

that doesn't seem to impact many people

The current output of $ llvm-config --system-libs is broken. This affects Crystal, Zig users at least. And will force them to patch the output of llvm-config on the fly.

I submitted the patches from Homebrew/formula-patches#303 at https://reviews.llvm.org/D87590, received some feedback in both places, but the output is that 10.x won't be patched and that 11.x might be affected.

This affects Crystal, Zig users at least.

And likely, there are other users who benefit from the updates and bugs fixed in the point release. Downgrading would also probably break things for a lot of users, this is why we do it only in extreme cases.

The right course of action is to fix the issue, submit the fix upstream. We would be willing to include it, if it benefits users, even if llvm will not do a further point release.

Regarding the patches you submitted, were they not incorporated in the formula already?

This is impacting the TVM community. In my experience there are a lot of transient issues that are fixed by starting XCode and restarting the computer after an XCode update. However, this issue is rooted in llvm-config not returning the correct library name for libxml. I can confirm that when built from source (after XCode upgrade and reboot) the homebrew build of llvm works great. What I'm wondering is why the llvm binary build for homebrew (a bottle I think? I'm not entirely familiar with the brew terminology) produces an llvm-config that produces the same error. It seems like there should be a solution to deliver a build that works.

If the issue is related to our build being built on an older version of Xcode, and needed to be rebuilt with Xcode 12, we can do that (create new bottles). But there are conflicting reports on whether rebuilding actually fixes the issue.

This also affects all my colleagues using Mac. This might only affect people who link against LLVM, but that seems a significant use-case for keg-only formulas.

If the issue is related to our build being built on an older version of Xcode, and needed to be rebuilt with Xcode 12, we can do that (create new bottles).
But there are conflicting reports on whether rebuilding actually fixes the issue.

As a data point, rebuilding from source forced me to upgrade Xcode/CLT (which took a few tries, with weird behavior from Apple software), but then provided a fixed version. There’s no evidence until now the current bottles have the right behavior for anybody.

I totally understand the frustration here. macOS is not really a platform that lends itself to consistency and ability to reproduce successful builds across releases. I also want to express my appreciation for everyone working on this and on homebrew in general.

My primary question is why this patch wasn't reflected in the bottle. Is there something funny that happened in the build? What's really strange to me is that all of the diffs from that patch seem to address zlib, but I don't see anything new that addresses the library suffix that's causing all of the problems. Before that patch was sent, were people able to build from source successfully?

Within the TVM community we have a document that describes how to build from source using Homebrew and also alternative packages that folks can use, so it's not a show stopper.

why this patch wasn't reflected in the bottle

The new bottles were rebuilt with the patch: you can check the date they were committed, and we have checks in place. Every merged PR goes through a full build on our CI machines.

I 100% understand if this is not the way to move forward. I wanted to keep iterating in the search for a fix that will be helpful practically.

@hogepodge I can't answer why the patch fixes things locally. I tracked & cherry pick commits that made sense from llvm repo & issue tracker until my local build worked. I am far from familiar with llvm code base and the build tools used there.

For the record, my environment is.

$ xcodebuild -version
Xcode 11.3.1
Build version 11C505

$ sw_vers -productVersion
10.14.6

@bcardiff I really appreciate the change set. It gave me a path forward in my environment.

% xcodebuild -version
Xcode 12.0.1
Build version 12A7300

% sw_vers -productVersion
10.15.7

Seems you need Xcode 12 on macos 10.15?

$ sw_vers -productVersion
10.15.7
$ xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
$ /Library/Developer/CommandLineTools/usr/bin/clang --version
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

We need someone to confirm whether the issue is with Xcode 11 and disappears when built with Xcode 12. Rebuilding from source doesn't give us enough information to tell whether doing a rebuild would actually fix the problems users are experiencing with LLVM. We have updated our CI to use Xcode 12 on Catalina, but it seems that Mojave users (with Xcode 11) don't experience this issue when building from source so it's not clear whether the Xcode version is actually the culprit.

We need someone to confirm whether the issue is with Xcode 11 and disappears when built with Xcode 12.

On Catalina the build failed until I upgraded, with LLVM explicitly saying it could not determine the version of xcode (or of clang? But I think the error did say xcode). @hogepodge, did you see something similar?

@jonchang Can Homebrew build bottles without deploying them? Alternatively, can we add a test to the bottle? It seems we can test for this bug using grep.

You can make a pull request adding the test to the test block. That would rebuild the software.

I'm closing this. There is a PR for the update to 11.0.0: #62798