-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
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
cc-wrapper: deunify clang/gcc handling of -B
flag
#225846
Conversation
Running a rebuild with this. It definitely fixes I think the big lesson from this issue and #225220 is that the |
This fixes parts in llvmPackages_{13,rocm} e.g. build .clang for testing. Longterm mass-rebuild fix should come in PR #225846
Yeah, that's unfortunate. I think Longer term we might need to avoid aliasing |
Fixed merge conflict. |
At some point (well after the 23.05 release) I would like to try putting They are effectively compiler intrinsics just like |
Yes all of them. I'm not sure if the |
@ofborg eval |
Well that's not good. |
It's kinda hard to figure out what that commit does since it doesn't have a PR... it just got lumped in with a 250-commit merge in #224806 |
@ofborg eval |
I merged master to staging, which should hopefully fix evaluation, but the very same line also caused a conflict here. |
@vcunat will this make it into the 23.05 release? This causes a mass rebuild, so if it doesn't make the release it is unlikely to be backported and we'll be stuck with the |
There's still a whole month until schedule says restricting breaking changes on |
Reverting d0bb9ed caused Apologies for the image, I cannot copy text from the output without cancelling the remaining rebuilds. Edit: after building the branch over the past two days, I am left with the following failures.
Full build logs for failing derivations https://gist.github.com/matthewpi/647099ecaa6083abe64e11eef2506417 |
@matthewpi thank you for checking this. And for spending two days of builder time on it. This was my mistake, I should not have reverted that commit.
@vcunat, sorry for not looking at this more closely. I have dropped the revert from this PR. |
@matthewpi: |
I wasn't sure, but luckily these are the only two failures I've noticed so far. I'll look into building the new changes "tomorrow", hopefully without anymore issues. |
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.
Fixes the rocm and LLVM-related build failures I've had on staging.
Does this also fix building
|
No, this PR does not address auto-patchelf errors, though they were introduced by the PR with gcc bootstrapping changes. Packages not built on Hydra get easily missed. Individual packages are easy to fix (e.g. see ab1cc58), but maybe we should have a generic fix for |
@orivej can you please open an issue with a bug report for this build failure (including a specific nixpkgs commit and exact It's probably my fault. Please assign the issue to me and I will fix it.
I think so too: If @orivej's problem turns out to be due to this then that will be the second issue report, and I will start working on a general |
Closes #225779
Closes #225780
NIX_CFLAGS_COMPILE+="v"
-then-nuke-refs
-then-diff
gives:https://github.com/gcc-mirror/gcc/blob/5582ad0afb051a76231b2959487f4ef1746df283/gcc/gcc.cc#L549-L551
Which is implemented as:
https://github.com/gcc-mirror/gcc/blob/5582ad0afb051a76231b2959487f4ef1746df283/gcc/gcc.cc#L6423-L6435
Which comes from:
https://github.com/gcc-mirror/gcc/blob/5582ad0afb051a76231b2959487f4ef1746df283/gcc/gcc.cc#L4505-L4506
So the root problem is the first red-text block in the image above. Once that
-B
is in there,gcc
will automatically add the offending-isystem
flags due to thespecs
file.So it's just that one extra
-B
that's causing all the trouble.