-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installing llvm on macOS Sonoma 14.2.1 with M3 processor fails #18
Comments
Looks like LLVM 16 added a dependency on zstd: https://www.phoronix.com/news/LLVM-16.0-Released I get
On opam, the |
Ah, I see you are using Homebrew and zstd is installed. I don't have a Mac, so I will likely need your help to troubleshoot this... |
Okay, I was able to reproduce this on Linux. When I try to compile the following test program: #include <llvm-c/Core.h>
int main()
{
LLVMContextRef ctx = LLVMGetGlobalContext();
LLVMModuleRef m = LLVMModuleCreateWithNameInContext("mod", ctx);
LLVMDumpModule(m);
LLVMDisposeModule(m);
return 0;
} The following works:
but the following does not:
|
On my system, it appears that the OPAM package finds So I think there are two issues going on here. First, the issue with Both are bizarre. The package fails to install because it cannot find |
One final note. I previously installed this same package on an older, Intel-based iMac running macOS Catalina or Big Sur (I can't remember exactly). I had no issues with it then, and from what I can tell neither the OPAM package nor LLVM has changed in that time. I believe I installed it on that computer less than three months ago. |
Can you please try to compile the C program I posted using:
and tell me the result? Using the same flags that are used to compile the OCaml package, I am getting an issue compiling the test program on Linux purely using the C API (without any OCaml), so I suspect that the OCaml package is also passing the wrong flags somewhere. Then, I am worried that some broken state in the installation may somehow cause cascading errors, leading to the second error. When I compile the OCaml bindings from the LLVM source tree directly, I do also get those warnings, but nothing should have been promoted to a hard error. EDIT: Would it be possible for you to tell me the result of compiling the C program on both macOS Sonoma and macOS Catalina or Big Sur? I am curious if merely compiling the C program leads to either a success or an error on different macOS versions. |
I had to make a minor modification to the commands you gave me because the Homebrew version of LLVM is keg-only as follows:
The first succeeds but the second does not. It gives this output:
Unfortunately I cannot test this on my older computer as I no longer have it. |
It appears |
Okay, thank you for giving the output. I ran
I checked my package manager and I have the
Then, I installed
Looks like adding a dependency on |
Actually, the |
The command
and macOS system
|
Interestingly, Homebrew doesn't indicate that |
Thank you for bearing with me. I'm not a Mac person and I realize that I haven't been very clear in all my posts on this issue tracker; I'm just poking around and trying to troubleshoot despite not having access to a Mac. I'm trying to think if this is an issue with the Do you think this is an issue with the |
Also, the LLVM 16 opam package was published on October 11, less than three months ago, while the LLVM 15 opam package was published on September 4. LLVM 16 added a dependency on zstd. You state that the LLVM installation was working "less than three months ago." I don't know how the dates line up with you; is it possible that you had LLVM 15 installed before (which did not depend on zstd), so the installation worked, but now you can't install LLVM 16 due to issues related to how zstd is packaged on Homebrew? |
So it appears I was wrong w.r.t. the symlinking: Homebrew on Apple silicon (Apple's M-series ARM processors) uses It is interesting though that the problem you linked to also occurs on an Apple silicon iMac. Could the package be trying to find
It is not possible that I had been using LLVM 15. I'm certain I had LLVM 16. So I must have installed it at some point after October 11th. |
According to |
Earlier I stated that |
I also found this issue: https://discourse.llvm.org/t/kaleidoscope-on-m1-mac-help/69010 My current suspicion is that Mac (and perhaps this has to do with the new M1 Macs) broke something related to library search paths that is causing issues when linking to zstd. I am interested in what the search path is when ld looks for zstd. |
From what I've been reading (see here), Homebrew switched from So in summary, yes, that is exactly what appears to have happened, but Homebrew can't fix it. It's worth noting that |
Given the installed |
I'm reading about this Homebrew change and thinking about the best solution. I found a big discussion about this change over at Homebrew/brew#9177. The issue states:
So, the primary reason for the change is so that Intel-based binaries and ARM-based binaries can coexist during migration to Apple Silicon. A secondary reason for the change is that fxcourdert says: Homebrew/brew#9177 (comment)
and Homebrew/brew#9177 (comment)
So, I am getting conflicting messages about the intent of this change. It seems that the Homebrew developers specifically don't want other tooling to find Homebrew-installed libraries by default, while acknowledging that it will break other software? Does Homebrew recommend a specific way to make its installations visible to other software by default? |
In the past, Homebrew installed symlinks into
My reading of this is that they don't want to change the old behavior, and the distinction exists primarily to allow the coexistence of Intel and ARM binaries during the transition to Apple Silicon. Note also that the default prefix is changeable, which addresses the use-case of users that don't want Homebrew packages to be found by default.
My interpretation is that the primary reason for the change was to allow the coexistence of Intel and Apple Silicon binaries. I doubt their primary intention was to make Homebrew-installed software not discoverable by default, as they have both keg-only packages (to eliminate conflicts with macOS system software) and the option to change the default prefix (allowing for users to make Homebrew-installed software not discoverable by default). I really hope that wasn't their intention, because I don't see the point of a package manager that doesn't put installed binaries in
With the exception of keg-only software, all Homebrew software is visible by default. For keg-only packages, Homebrew has a "Caveats" section in the package info telling you how to access it. (For instance, the caveats for LLVM mention the appropriate |
Note that the problematic package is zstd, not LLVM. zstd does not have a "Caveats" section. zstd is not a "keg-only" package.
I agree that the main reason why Homebrew changed prefix is to allow Intel and ARM binaries to coexist. The reasoning in the Homebrew issue about not wanting Homebrew installations to be visible by default, or interfere with other installations in If software is installed in a non-standard location, I don't think it's LLVM's responsibility to automatically find it. If I save a zstd shared object file in some random location, why should I have a fix at https://github.com/alan-j-hu/llvm-dune/tree/llvm-16-homebrew. It adds a new dependency on |
I disagree with this.
The purpose of
I don't think the issue is with
I think that's a wonderful idea. I would test it on my machine for you but I don't know how to configure OPAM to use the release. As stated earlier, however, I think the real issue is with either |
I managed to figure out how to add the updated package to OPAM, but I get this error:
|
According to this comment, Homebrew believes this to be a problem with |
When I run I looked at the zstd "formula" on Homebrew. Is this line why |
From what I can tell, yes. |
See here.
The text was updated successfully, but these errors were encountered: