-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
glibc: don't use bootstrap libgcc_s #36948
Conversation
No attempt on x86_64-darwin The following builds were skipped because they don't evaluate on x86_64-darwin: glibc No log is available. |
Success on aarch64-linux (full log) Attempted: glibc Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: glibc Partial log (click to expand)
|
Yep, |
build log of the failure, for the curious: https://gist.github.com/dtzWill/9aea1fb5695788fcb0a63c96f32d36d4 This is the error we currently find w/trying to use clang as a cross-compiler, which is what started me looking into all of this :). cc #36867 |
@dtzWill if you are at it, could you maybe also teach clang to find c++ stdlib headers without compiler wrappers on linux? This would fix all tooling that uses libclang. I tried to fix it in https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/Linux.cpp#L758 but this only affects clang from a build directory. |
that one looks also interesting: https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/Linux.cpp#L804 |
Yeah we need to get change GCC at some point so the compiler itself and runtime libraries are built separately. That will make the one problem caused by this go away! |
Hmm, I suppose we can afford this now that we have |
Hmm, I think this issue is currently making some builds fail for 18.03, esp. ones that are required for the channel to move forward and actually come into existence (spidermonkey_38 for i686 in particular is required by tests that are required for 18.03, if I read hydra correctly). Would it make sense to merge this PR into (cc ZHF #36453) |
Eh, better not do such experiments directly on 18.03 anymore. After it's confirmed that this works good, we can cherry-pick it in 18.03. We may have a separate temporary jobset if you think there's a risk of mass breakage, but I suppose it won't be that risky. |
Plus 18.03's tested job already succeeded so as I understand it this shouldn't block channel updates (I can't see the channel being created yet but I suppose that's a different issue). |
Perhaps a new jobset would be appropriate then? |
@pbogdan oh indeed, I was misreading the jobs tab as the tested job, because I didn't understand why 18.03 hadn't been created yet -- my reasoning was completely wrong, then, sorry for the noise :) |
I added the 18.09 milestone because I definitely want this to happen by then. Not trying to say it shouldn't also happen for 18.03 :). |
For reference, the 18.03 channels are there now, for about a day. The machine bumping them wasn't immediately re-deployed with the new configuration, by mistake. |
Can we still do this? A quick hack for LLVM in cc-wrapper should be easy enough. |
Agreed, and we can probably improve the libclang situation while we're at it. Definitely want this to happen, just not sure when :) |
Doing this would make everything that needs on |
We soon will for compiler-rt! #39743 |
Timed out, unknown build status on x86_64-linux (full log) Attempted: pkgsi686Linux.dejagnu Partial log (click to expand)
|
The underlying problem with libgcc is worked around. (cherry picked from commit afea12f)
38b17f5
to
ff30d7b
Compare
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: glibc Partial log (click to expand)
|
Success on aarch64-linux (full log) Attempted: glibc Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: glibc Partial log (click to expand)
|
8d7d962
to
e26c8aa
Compare
e26c8aa
to
2ed8ee4
Compare
FWIW |
|
@dtzWill is there any way to avoid these issues? I still like getting rid of references to libgcc... But it may need to wait for another time? |
Ok let's revert for now. ideally we can get this fixed at a later point. 319ebef is the revert. |
Aww can't reopen this? 😿 Suppose can always make a new one if someone finds time to tackle the issues. Not sure I prefer the current state (subtle issues everywhere) over breaking things explicitly and forcing the issue, but that's just me O:). Probably not best to do that with a release looming, I admit... :) |
Let's try this again. See NixOS#36947 and NixOS#36948 for history
Let's try this again. See NixOS#36947 and NixOS#36948 for history
I figured out the root cause of these segfaults. |
Fixes #36947
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)Huge rebuild, have not tested everything obviously :).
Wanted to see what broke and was surprised to find
that things didn't immediately and completely break.
I'm curious if clang works after this, we'll see!