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 DetailsApologies 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. DetailsFull 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. |
matthewpi
left a comment
There was a problem hiding this comment.
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-diffgives: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
-Bis in there,gccwill automatically add the offending-isystemflags due to thespecsfile.So it's just that one extra
-Bthat's causing all the trouble.