homebrew-provided LLVM/Clang prevents zig from building C files #8860
Comments
|
Hm. After lots of retries, it seems to work now. But, I'm not 100% sure why. I suspect the necessary step was adding this to my set -ax LDFLAGS "-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
set -ax CPPFLAGS "-I/usr/local/opt/llvm/include"
set -x SDKROOT (xcrun --sdk macosx --show-sdk-path)
set -x CC /usr/local/opt/llvm/bin/clang
set -x CXX /usr/local/opt/llvm/bin/clang++There is a next step here, which is: change the wiki documentation to mention that these environment variables need to be added. |
|
Can you reproduce this with a precompiled snapshot downloaded from ziglang.org? |
None of this should be needed. Also, when reporting issues that are specific to the compiler (and leaving the linker out), it’s useful to force the C/C++ compiler to output a translation unit directly Could you paste the source of your C program? |
It doesn't happen anymore, and I'm not sure why. I tried it on the snapshot builds and those work fine.
The actual file I was trying to build is this: https://github.com/h2o/picohttpparser/blob/master/picohttpparser.c But, the issue happened with a file as a simple as: #include <sys/types.h>
int main(int argc, char *argv[]) {
}In-case it's helpful, this was the output from
|
|
Huh, fascinating! You’ve got the same problem as @jedisct1 it seems. Note that in the last error message, your include path has two |
|
Lemme try and come up with a patch, but I’d be indebted if you could try it out before we commit anything in into master. Would that be ok with you @Jarred-Sumner? |
Happy to try it, but I'm not sure if it will be useful unless we can reproduce the issue happening again for the same reason. I'm rebuilding another copy of zig in a different folder without the environment variables I mentioned earlier and seeing if that will put it into the state where it doesn't work |
|
Yep, that reproduces the issue. bad build: good build: bad build verbose: --verbose isn't printing anything with the working |
|
Still trying to figure out what's going on as well. This doesn't seem to be a recent regression in Zig. I went back as far as right after the LLVM 12 merge, and the behavior is the same. Setting up environment variables as described by OP doesn't make a difference either. However, builds from CI have the correct paths. |
I actually had some issues with |
|
OK, so @jedisct1 and I confirmed it’s a deficiency in zig ld. If you add |
kubkon
added
linking
bug
|
@jedisct1 still reports some problems with |
|
I think the extra |
|
Hi, just want to mention that I'm seeing a similar problem with the latest zig 0.8.0 dev versions on macOS when compiling C and C++ code (0.7.1 works fine), the header search path problem doesn't seem to only affect standard library headers, but also "regular" project headers. For instance I'm getting errors like this: That problematic header path Somehow the compiler doesn't seem to be aware of header search paths. The actual location of the include file is The location If you want to play around with it, the project is here: https://github.com/floooh/sokol-tools Clone with submodules, and then run zig build: This is a pure C++ command line tool, I'm currently experimenting with using zig as C++ build chain for cross-compiling :) |
Please never do anything like this. We need to fix the issue, not put bandages on it. |
|
Anyone in this thread who is experiencing the problem: do you experience the problem with a tarball from ziglang.org/download/ ? |
Nope, this doesn't happen with these tarballs. The culprit seems to be LLVM, as installed by Homebrew. |
andrewrk
changed the title
|
Strongly agree, I was unaware of the constraints. It’d be better to also
automatically handle doing the (brew —prefix llvm) part specific to macOS
as well, since currently building from source fails without that.
…On Sat, May 22, 2021 at 2:01 PM Andrew Kelley ***@***.***> wrote:
There is a next step here, which is: change the wiki documentation to
mention that these environment variables need to be added.
/usr/local/opt/llvm/ can be replaced with $(brew --prefix llvm)
Please never do anything like this. We need to fix the issue, not put
bandages on it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8860 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFNGS52HERDGIO5ZL57HNDTPALTBANCNFSM45KF72HA>
.
|
My build is still running, but it appears that the official tarball doesn't have this problem, and it's instead a problem in the brew-installed version. That's good to know! I guess a lot of people on macOS will install via brew, maybe the brew-formula should be changed to install the tarballs instead? Tarball version is: 0.8.0-dev.2631+d321a4b76 (the brew version also has a small annoyance that PS: build has finished without problems |
|
Y'all, after some more debugging, this issue is with Homebrew and how LLVM is packaged rather than Zig. It turns out actually that we already dealt with it in the past back when we used LLVM-10: link. The meat of the issue is that currently, Homebrew distributed LLVM, configures
Both workarounds should get rid of the problem if you're building zig from source using system tools and Homebrew shipped LLVM. The end solution however will be to take it up with Homebrew devs themselves to work out a suitable patch. The issue is so much more annoying since this means that Zig distributed via Homebrew (built from HEAD) will inevitably be broken. |
|
Cant you pass custom CMake flags to the zig Homebrew script so at least
brew install zig —head works?
Cant cmake detect its on macOS, then detect if “brew —prefix llvm” returns
a zero status code, and then relaunch itself with the right config options?
…On Sun, May 23, 2021 at 12:30 PM Jakub Konka ***@***.***> wrote:
Y'all, after some more debugging, this issue is with Homebrew and how LLVM
is packaged rather than Zig. It turns out actually that we already dealt
with it in the past back when we used LLVM-10: link
<#4799>.
The meat of the issue is that currently, Homebrew distributed LLVM,
configures libLLVM for dynamic linking, while libClang for static
linking, causing some bizarre init order fiasco/interdependence which
results in the errors seen in this issue as well as other as reported by
you. There are two workarounds to this currently:
1. cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix llvm)
-DZIG_PREFER_CLANG_CPP_DYLIB=on which will force both libLLVM and
libClang to be dynamically linked, or
2. cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix llvm)
-DZIG_STATIC_LLVM=on which will force both libLLVM and libClang to be
statically linked
Both workarounds should get rid of the problem if you're building zig from
source using system tools and Homebrew shipped LLVM. The end solution
however will be to take it up with Homebrew devs themselves to work out a
suitable patch. The issue is so much more annoying since this means that
Zig distributed via Homebrew (built from HEAD) will inevitably be broken.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8860 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFNGSYY4YI6SCFU2DU47B3TPFJUTANCNFSM45KF72HA>
.
|
But this wouldn't be fixing the underlying issue, would it? It's always better to fix the issue at its root rather than put a bandaid on top of it. I've now made sure that when we release 0.8.0, homebrew's CI will reject any zig formula bumps until this issue is resolved, and in the meantime, I'll try resolving it myself and submitting a patch to homebrew. |
|
Some more update on this issue. Today, I went as far as installing homebrew on a linux laptop, and replaying all the steps just as we'd do them on macOS. To my surprise, everything works just fine and I should note that I'm investigating the former as we speak. |
|
Just an FYI that I submitted a bug report downstream Homebrew/homebrew-core#78025 |
Alas, I've got some bad news. This workaround doesn't seem to fix everything. Regardless if you add either flag to CMake, the resultant build of zig while passes the augmented Homebrew tests, it fails at stage2 tests which involve pulling in LLVM: Why that is, I have no idea, and I'll need to investigate further. I will also report this result downstream. |
OK, better news, this only happens with zig master built using homebrew |
|
Nvm, I think this might be a regression in zig itself as I can repro this regardless of whether brew's LLVM was used or not. |
|
Homebrew/homebrew-core#78336 which fixes this in Homebrew has been merged. |
|
Great news! 🎉 |
|
Closing as it's been fixed in Homebrew. However, I also note that there is one final bit of functionality missing in |
Note from @andrewrk: A workaround for this is to use the tarballs from the download page.
zig version:
0.8.0-dev.2591+4b69bd61emacOS version:
11.3.1To repro, run this:
Response:
Passing the include path does not fix it:
This is consistent, whether it's
zig translate-c,zig cc,@cInclude, orexe.addCSourceFileetc.Initially, I thought it was something specific to my environment -- but after wiping my hard-drive & reinstalling macOS, it's hard to see how it could be.
Note that llvm 12 is installed and this occurs whether it's a copy of zig built from homebrew or manually running
cmakeThis seems to work on zig 0.7.1, so this seems to be something that broke recently:
After adding a main function,
zig 0.7.1can build it, but zig onHEADcannotThe text was updated successfully, but these errors were encountered: