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
libgcc: Init at 7.3.0 #44069
libgcc: Init at 7.3.0 #44069
Conversation
export AS_FOR_TARGET=${stdenvNoLibs.cc}/bin/$AS_FOR_TARGET | ||
export CC_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CC_FOR_TARGET | ||
export CPP_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CPP_FOR_TARGET | ||
export LD_FOR_TARGET=${stdenvNoLibs.cc.bintools}/bin/$LD_FOR_TARGET |
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.
This, GHC, and the cmake setup hook all demonstrate that we really need to change binutils-wrapper to make these full paths across the board, not just names on the PATH.
I did something similar in #40637, the primary motivation was to build gcc+winpthreads to support c++11 threading features. That however turned out to produce libraries that behaved subtly different from those built with the msvc. As such I did not persue that further. Building with libwpthreads requries building gcc (no libs), then winpthreads with that gcc, and finally the rest of the libs to package it all together. So this migth just work out right with this appraoch. |
Oh! I somehow missed that and assume you never upstreamed it. My bad! |
Are you saying that your old PR didn't work, but this might? Or just that whole window rebootstrap is doomed? |
It's not upstreamed and it's not perfectly working. Yes. I think this might be a clearer approach; you've got way more experience with the low level details (doh!). But maybe there's a nugget or two you can use :-) |
Well this wouldn't fix any C++ ABI issues with GCC, but it might make cross with LLVM easier, and LLVM on/for Windows has recently seen a lot of work. I'll be sure to take a look at that your stuff! |
Failure on aarch64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
Failure on x86_64-darwin (full log) Attempted: libgcc The following builds were skipped because they don't evaluate on x86_64-darwin: libstdcxx5 Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
This will be very useful for bootstrapping, eventually.
Failure on x86_64-darwin (full log) Attempted: libgcc The following builds were skipped because they don't evaluate on x86_64-darwin: libstdcxx5 Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: libgcc, libstdcxx5 Partial log (click to expand)
|
Motivation for this change
I want to start from this, and work towards packaging all the libraries this way. Then we can:
libc
).libgcc
is hard to build on its own, but the each derivation will be much simplerlibstdc++
separately forlibstdcxxClang
This is analogous to @kirelagin and @matthewbauer's work rebuilding GHC wired-in libraries.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)