-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
llvmPackages_15.libcxx: specify LIBCXX_CXX_ABI_{LIBRARY_PATH,INCLUDE_PATHS}
for all cxxabis
#216273
llvmPackages_15.libcxx: specify LIBCXX_CXX_ABI_{LIBRARY_PATH,INCLUDE_PATHS}
for all cxxabis
#216273
Conversation
llvmPackages_15.libcxx
: fix linker script bug
any update on this? |
@SchrodingerZhu I'll work through the remaining TODOs in the next couple of days; is this blocking something else for you? |
Nothing urgent. I am just hoping to setup an LLVM15 environment with |
This is probably also required for LLVM 16. |
Apologies, once again, for the delay; I should have time to finish this and the remaining issues in #213033 this weekend.
I believe this actually isn't; as mentioned the patch we're applying here is present in LLVM 16. We'll see though; the goal of the other half of this PR is to actually test the LLVM stdenvs a bit so we can catch issues like these 🤞. |
Oh I totally overlooked that. Sorry 🙏
Does the nixpkgs CI run global tests with the LLVM stdenv on x86_64-linux (with glibc, not with musl)? I keep running into curious issues that make it seem like the LLVM toolchain is not really tested against downstream projects. I also noticed that there is no build cache for Maybe it would make sense to dogfood the LLVM toolchain to a few buildsystem packages like CMake, Meson and Bazel? The tests for such packages might be a helpful sanity check. |
no worries!
I'm not the expert here but I believe the most testing the LLVM stdenv currently gets (outside of packages that explicitly use it in their builds) is this (builds the stdenv but does not use it). This PR adds the
Definitely! My experience matches yours: I've seen lots of breakage when trying to use the LLVM stdenvs, in their various forms; better testing seems undoubtedly valuable here. At the moment though, I've been focusing on trying to deduplicate the LLVM package sets (which will make it a little easier to introduce tests and fix bugs and such). |
We should definitely extract the cc-wrapper tests stuff and merge it ASAP, for the rest, it can wait ofc, but I am available to work on reviewing or helping on that. :) |
Any word on when this can be merged? I have a package requiring LLVM 15 which I am unable to build without this patch. I also needed the change mentioned by @LogicalOverflow here. |
+1 would also love to see this merged. I'm on macos right now (so no linux box). Is there anything I can do to help? |
I'll take a look at this tomorrow; IIRC I still needed to look at the proposed fix here and spin off the |
Hi @rrbutani. Did you have any success? |
Test changes split to #253752 |
99b2500
to
5786324
Compare
b54b7e4
to
746ceb3
Compare
# - https://reviews.llvm.org/D133566 | ||
# - https://github.com/NixOS/nixpkgs/issues/214524#issuecomment-1429146432 | ||
# !!! Drop in LLVM 16+ | ||
(fetchpatch { |
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.
I've split this to #253936 as it's ready while the other issue still needs reviewing
…_PATHS}` for all cxxabis Previously we only specified `LIBCXX_CXX_ABI_INCLUDE_PATHS` for `libcxxabi` and not for `libcxxrt` which causes `libcxx`'s build to fall back to looking in `/usr/include/c++/v1`: https://github.com/llvm/llvm-project/blob/aa656f6c2dec73faceeed21e15401d8f0c743c8b/libcxx/cmake/Modules/HandleLibCXXABI.cmake#L148-L151 We didn't set `LIBCXX_CXX_ABI_LIBRARY_PATH` (and this did not seem to be a problem; I think this gets defaulted elsewhere in the `libcxx` build) but it doesn't hurt to.
2a82460
to
a26d168
Compare
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.
are both of the changes needed or only one or is the libcxx/default.nix change unneeded or is it needed in 16 too
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.
AFAIR, LIBCXX_CXX_ABI_*
doesn't exist in 16, which is why I introduced the change to include it via the clangUseLLVM
wrapper.
There could be further issues lurking within the LLVM build; some time around LLVM 16 they moved things to assume that you're doing an in-tree build and that libcxx can access libcxxabi's headers; I see that nixpkgs has worked around that to some degree.
I don't fully understand how libcxxabi should get into the compilation environment for nixpkgs, whether it's really a part of libcxx's install or not for example. I consider what I did above as a bit of a hack.
185dc1b
to
906d39b
Compare
llvmPackages_15.libcxx
: fix linker script bugLIBCXX_CXX_ABI_{LIBRARY_PATH,INCLUDE_PATHS}
for all cxxabis
What is preventing this from being merged? |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/1688 |
I understand this was fixed, I think by #307184. Sorry that this stalled out! |
Description of changes
This PR mostly just fixes #214524 but also takes the time to:
tests.cc-wrapper
to test moderngcc
/clang
stdenvs (these tests catch the issue in llvmPackages_15: Building withclang++
usinglibcxx
/-stdlib=libc++
fails #214524)libcxx
build flags that we were missing: 6828e23TODO:
cxxrt
)tests.cc-wrapper.*
tests passllvmPackages_git
as wellllvmPackages_16
as is appropriateThings done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)