Add mingwW64-llvm cross-system. #171418
Add mingwW64-llvm cross-system. #171418
Conversation
shlevy
requested review from
matthewbauer,
Ericson2314,
alyssais and
nbp
as code owners
|
Easiest reviewed commit-wise. |
Mindavi
added
6.topic: cross-compilation
|
This generally looks good to me. It looks like you made some attempt to backport changes to older LLVMs to keep things consistent? That's good. I asked @sternenseemann to review too. There's a lot of new passthru items and I think they are OK, but it's a good thing to get a second set of eyes upon. |
|
@Ericson2314 llvm 14 is not yet working fully, so this actually uses 13 by default. I forward-ported the changes to 14 so they won't get lost as llvm gets upgraded |
| @@ -17,6 +17,7 @@ | |||
| , isGNU ? false, isClang ? cc.isClang or false, gnugrep ? null | |||
| , buildPackages ? {} | |||
| , libcxx ? null | |||
| , isCompilerRT ? false | |||
There was a problem hiding this comment.
Isn't useLLVM the only way to get a compiler-rt stdenv.cc at the moment? stdenv.hostPlatform.useLLVM or false should also be a feasible replacement.
This disambiguator is probably useful regardless, but I'm wondering if we should be conservative about what we tack on here and if there's possibly a better system for this?
There was a problem hiding this comment.
No, you can use this with llvmPackages.tools.clangUseLLVM etc.
Probably there is a better system. e.g. something like compiler-rt is perhaps plausibly an attribute of the platform (if it's required to be consistent across libraries and executables being linked together) whereas something like the linker really isn't (at least on platforms where there are multiple interchangeable linkers). But I'd prefer to separate out these improvements to how these are handled from the functional addition in this PR, unless there's a better current alternative.
There was a problem hiding this comment.
@sternenseemann yeah I think this is good too. useLLVM is kind of a sledge hammer when we ought to support more mix and match. I would not be opposed to specifying the default like we do for the linker in the platform description, but non-default compilers can do different things so we can track in the wrapper too.
| "-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=TRUE" | ||
| "-DLIBCXX_CXX_ABI_LIBRARY_PATH=${libcxxabi}/lib" | ||
| ] ++ lib.optional (!headersOnly && libcxxabi.useLLVMUnwinder) | ||
| "-DLIBCXXABI_USE_LLVM_UNWINDER=ON"; |
There was a problem hiding this comment.
Curious about this; libcxx/CMakeLists.txt claims this is only about linking the test cases which we don't run.
There was a problem hiding this comment.
I got link errors without this, I wouldn't be surprised if it's only needed when LIBCXX_ENABLE_STATIC_ABI_LIBRARY (which is narrowly tested).
There was a problem hiding this comment.
In which versions, @sternenseemann? I don't see that in LLVM 13's libcxx/CMakeLists.txt.
There was a problem hiding this comment.
I was looking at LLVM 9, but the comment is still there on main: https://github.com/llvm/llvm-project/blob/7e3ef7dcd2b8201dce671237857f04a1d527d580/libcxx/CMakeLists.txt#L297-L298
You should do |
|
This will now be a mass rebuild on llvm systems, will rebase on staging once all open issues are addressed |
ofborg
bot
added
8.has: clean-up
10.rebuild-linux: 101-500
and removed
10.rebuild-linux: 11-100
labels
shlevy
force-pushed
the
mingwW64-clang
branch
2 times, most recently
from
bd10e11
to
2788ead
Compare
This is expected e.g. by the GHC cross-compilation code
Fixes autotools checks parsing --help
libtool upstream seems quite slow to merge...
By specifying pkgs.libffi here instead of letting callPackage handle it, we confuse the splicing logic and put the host libffi into NIX_LDFLAGS_FOR_TARGET. This previously hasn't been a problem, as we also pass an explicit configure flag pointing to the target libffi, and so the only side-effect is a senseless -rpath flag. ld.lld (rightly) does not recognize the -rpath flag when targeting Windows, however, so this causes build failures.
|
@Ericson2314 @sternenseemann OK looks like I've addressed all outstanding issues, any remaining concerns? |
|
@Ericson2314 @sternenseemann Any further thoughts? |
|
Can you revert this merge, please? The second staging-next iteration for 22.05 has not yet started and LLVM is considered release critical, so potentially breaking changes are disallowed. See also #165792 I'd also like to have another look, didn't find the time in the last week unfortunately. |
|
Is there some way we can contort this to be a non-mass-rebuild just for 22.05? |
|
@sternenseemann Ah I didn't realize |
|
@Ericson2314 We could make the libtool patching conditional. Any strong reason to do so? |
|
PR to add this back in up at #173498 |
rrbutani
added
the
6.topic: llvm/clang
This adds a new cross system targeting mingwW64 + ucrt using an llvm-based toolchain.
Similar in spirit to and inspired by @mstorsjo's https://github.com/mstorsjo/llvm-mingw.
Among other benefits of LLVM + ucrt, this will be necessary to build a GHC compiler targeting Windows in 9.4 or later.