-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
llvm: factor out compiler-rt, fix libstdcxxStdenv sanitizer headers #39743
Conversation
LGTM. It's unfortunate that no one knows why we built this as part of LLVM in the first place. Did something need it? xD. But a variety of very basic testing shows things working as they should, on both glibc and musl. Do none of the other components need or benefit from compiler-rt? Also, might be worth doing the same for LLVM5 and seeing what the Darwin builders think of the change-- to exercise clang-based stdenv's and get ahead of possible problems when eventually moving to LLVM6 as default. Does this sound reasonable, @NixOS/darwin-maintainers ? Have some build cycles to spare? :) |
Would it be much work to put together a little test for the behavior this fixes, and add it as a cc-wrapper test or something? So we can (try to) avoid regressing on it. Just a thought :). |
IIRC we hunted down the party responsible (@shlevy?) in IRC and they were reasonably confident that it was just a workaround for historical brokenness in the LLVM build system--its degree of support for compiling components separately has varied in the past.
Such a test should be simple, especially if you can point me to an example cc-wrapper test to model it on, as I haven't written a NixOS test before. Is there any danger of planting a land mine for support of compilers that don't implement the usual sanitizers, though? I imagine e.g. icc might be an issue. |
Factoring compiler-rt out of LLVM doesn't have to happen simultaneously with fixing the bug in the clang package, but they're both going to touch clang so it's probably worth getting the rebuilds out of the way in one go. |
We have various cc-wrapper tests that are specifically for clang -- various versions, using libc++ and libstdc++. I think perhaps they could go there? https://github.com/NixOS/nixpkgs/tree/master/pkgs/test/cc-wrapper Anyway this can happen in a follow-up and as time allows :). |
Yes, I definitely wanted to compile this separately from the get-go but it didn't work way back when I added it. |
Oh, well that settles that! I didn't mean to place blame in any way--often details of a decision are lost over time :). Anyway thanks for clearing that up! |
Basic testing suggests this is fine but I'm a bit too swamped to more thoroughly review/test. Don't block on my account, sorry! |
Is this blocked? |
Can you rebase to staging? Otherwise looks good. The build farm is a little busy right now but I can merge after that clears up. |
Woah!!! Very very very excited this exists. |
inherit version; | ||
src = fetch "compiler-rt" "16m7rvh3w6vq10iwkjrr1nn293djld3xm62l5zasisaprx117k6h"; | ||
|
||
nativeBuildInputs = [ cmake python llvm ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure LLVM is just a build tool here? So it is a nativeBuildInput
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reallllyyy??? No wonder you were asking about using a stand-in for llvm-config, wonder what the details here are.
OK I did the merge. This should be good now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM, haven't tested extensively but don't expect much to break.
TYVM for moving the musl patching over 👍.
inherit version; | ||
src = fetch "compiler-rt" "16m7rvh3w6vq10iwkjrr1nn293djld3xm62l5zasisaprx117k6h"; | ||
|
||
nativeBuildInputs = [ cmake python llvm ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reallllyyy??? No wonder you were asking about using a stand-in for llvm-config, wonder what the details here are.
@@ -51,13 +53,17 @@ let | |||
outputs = [ "out" "lib" "python" ]; | |||
|
|||
# Clang expects to find LLVMgold in its own prefix | |||
# Clang expects to find sanitizer libraries in its own prefix | |||
# Clang expects to find sanitizer libraries and headers in its own prefix | |||
postInstall = '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyone have details about this?
Also discussed elsewhere in this PR (#39743 (comment)) -- I'd just like to know about the issues, as it'd be awfully nice to not have to link these bits over... (perhaps combined with a wrapper or so).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll see if it's possible to get away with -L
and -isystem
for these. The approach taken here was based on the existing code and the expectations of the clang developers, but it isn't necessarily impossible to do otherwise. If it works out, how would I go about injecting them gracefully?
e: Wait, now I think I get what @Ericson2314 was suggesting. Will experiment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! If it's a big deal, we can look into it later--don't mean to push all of our LLVM-related TODO's onto your PR! 😁
But if you don't mind taking a look that'd be great! Thanks!
FWIW initial musl testing looks good! Woo! 👍 |
OK rebased on some careful cherry-picks so there's no conflicts. If we can make |
Also the separate "tools" and "libraries" part of obsidiansystems@acf2ed5 would be nice to have. I might try to incorperate that. |
Contrary to my initial reaction, |
64106b4
to
d9458a9
Compare
Only the wrapper script knows about compiler-rt, and both tests pass! |
…er headers Build compiler-rt separate from llvm and clang, and just add as an extra library in the wrapper.
llvm 6: Master version of #39743
Motivation for this change
This fixes the libcxxStdenv build of projects that use e.g. the AddressSanitizer API to improve error detection when using custom allocators, and improves factoring.
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)