Build fails with clang/llvm due to C++26 #7508
Comments
|
CC @fufexan |
|
sounds like std version is not propagating properly |
|
@JohnRTitor can you pull again and check the logs for any occurrence of |
|
FYI: I guess Clang is using the Libcxx provided by GCC, instead of the one from LLVM... This should be a platform-specific issue. I had the same issue before in Gentoo. Changing the USE flag of ➤ ~/.dot-files/shell/.zshrc.d [master] $ equery u clang-runtime
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for sys-devel/clang-runtime-18.1.8:
U I
+ + abi_x86_32 : 32-bit (x86) libraries
+ + compiler-rt : Install sys-libs/compiler-rt for -rtlib=compiler-rt
+ + libcxx : Install sys-libs/libcxx for -stdlib=libc++
+ + openmp : Install sys-libs/libomp for -fopenmp support
+ + sanitize : Enable compiler-rt sanitizer (-fsanitize*) support |
|
should this be closed then...? |
|
I can build it with a ton of warnings, but it builds fine. It seems @yangyingchao is correct. His standard lib is messed up. Vax any specific reason why hyperpm still has |
I think so. |
|
I just haven't changed it and hyprpm doesn't need 26 unlike hyprland |
So it looks like CMake is finally passing a good flag ( |
|
This is that nixos moment. Edit: |
|
This was caused by #7219, This is probably the best option since many distro's will likely not support C++26 for quite some time. Being one of the maintainers for LLVM in Nixpkgs, I can't guarantee that we will actually support C++26 with LLVM in Nixpkgs. |
|
I guess C++26 might not be ready for widespread adoption for lots of distors in several years... So I'm afraid that this might block some people from upgrading to 0.43... |
JohnRTitor
changed the title
|
cmake dep bumped, so this can be closed. clang and gcc will build hyprland provided they are up to date (and so is cmake) |
Spec won't be finalized until January 2026 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1000r6.pdf). This means that the earliest which LLVM could implement support is July 2026. That is essentially two years from now.
That's for Nix, what should other distros do that don't have a new enough LLVM or GCC. Should everyone just compile the compiler just for this one package? |
This is plain wrong.
update their llvm/gcc before updating hyprland. |
2026.1 – tbd CD ballot comment resolution |
|
No, the wrong part is "This means that the earliest which LLVM could implement support is July 2026" Easily disproven by the fact clang18 supports the C++26 method we use. |
That is true however, not everyone is going to use the same C++ implementation. Most people do use libstdc++ and libc++ but not everyone might not. Plus versions which aren't finalized are not stable. Using a non stable version is a concern of mine because of possible side effects which could cause unwanted behavior during runtime. Another concern is people might not want to mix compiler versions, especially if it's an unstable version. |
|
once a paper is approved for C++26, it's approved. It won't be "un-approved". |
|
This is still an issue by the way @fufexan Tried to (vaxry: just use rust ;) |
|
@JohnRTitor $ c++ -std=c++26 -stdlib=libc++ -nostdinc++ -I /nix/store/c55xcry32njvs6q3b40qnsw283c4jdx2-libcxx-18.1.8-dev/include/c++/v1 -L /nix/store/pfdygjng4hdnwmnll4qmxnycxkkbbwla-libcxx-18.1.8/lib -Wl,-rpath,/nix/store/pfdygjng4hdnwmnll4qmxnycxkkbbwla-libcxx-18.1.8/lib native_handle_test.cppI got the syntax above from https://stackoverflow.com/a/65004156. |
If we could patch on the nixpkgs side, that would be great, this likely affects other packages as well.
I am not sure if there's a need to introduce seperate packages. |
That is kinda true, it's designed to use the main stdenv's C++ implement. You'll have to override it to use libc++ if you want to use that. |
|
Looks like hyprland> [233/250] Linking CXX executable hyprctl/hyprctl
hyprland> FAILED: hyprctl/hyprctl
hyprland> : && /nix/store/4wphwqdc7jz18nl9z2sda5ryafl4fm1y-clang-wrapper-18.1.8/bin/clang++ -O2 -g -DNDEBUG -Wl,--export-dynamic -rdynamic hyprctl/CMakeFiles/hyprctl.dir/main.cpp.o -o hyprctl/hyprctl /nix/store/gf5bjfck5c7sl4mdkbw8qawb3vw5xmyl-hyprutils-0.2.1+date=2024-08-29_8976e3f/lib/libhyprutils.so && :
hyprland> /nix/store/d828ccvc2148g7m49hh3mzvyzwpipy46-binutils-2.42/bin/ld: hyprctl/CMakeFiles/hyprctl.dir/main.cpp.o: in function `main':
hyprland> /build/source/hyprctl/main.cpp:343:(.text+0x3f43): undefined reference to `Hyprutils::String::isNumber(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)'
hyprland> /nix/store/d828ccvc2148g7m49hh3mzvyzwpipy46-binutils-2.42/bin/ld: /build/source/hyprctl/main.cpp:424:(.text+0x4c2c): undefined reference to `Hyprutils::String::isNumber(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)'
hyprland> clang++: error: linker command failed with exit code 1 (use -v to see invocation)
hyprland> [234/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/ext-session-lock-v1.cpp.o
hyprland> [235/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/presentation-time.cpp.o
hyprland> [236/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/xwayland-shell-v1.cpp.o
hyprland> [237/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/primary-selection-unstable-v1.cpp.o
hyprland> [238/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/tablet-v2.cpp.o
hyprland> [239/250] Building CXX object CMakeFiles/Hyprland.dir/protocols/viewporter.cpp.o
hyprland> [240/250] Linking CXX executable hyprpm/hyprpm
hyprland> FAILED: hyprpm/hyprpm
hyprland> : && /nix/store/4wphwqdc7jz18nl9z2sda5ryafl4fm1y-clang-wrapper-18.1.8/bin/clang++ -O2 -g -DNDEBUG -Wl,--export-dynamic -rdynamic hyprpm/CMakeFiles/hyprpm.dir/src/core/DataState.cpp.o hyprpm/CMakeFiles/hyprpm.dir/src/core/Manifest.cpp.o hyprpm/CMakeFiles/hyprpm.dir/src/core/PluginManager.cpp.o hyprpm/CMakeFiles/hyprpm.dir/src/main.cpp.o hyprpm/CMakeFiles/hyprpm.dir/src/progress/CProgressBar.cpp.o -o hyprpm/hyprpm /nix/store/6n7mjzp32m0srz21s5n82cgly7pg1h00-aquamarine-0.3.3+date=2024-09-01_f8a687d/lib/libaquamarine.so /nix/store/rnlflxkgglrdiii7wl7k99893zr4iamc-libxkbcommon-1.7.0/lib/libxkbcommon.so /nix/store/5dwg0biim3ws7a2hyadmvfzsazqcgkk5-util-linux-minimal-2.39.4-lib/lib/libuuid.so /nix/store/0xxjgp8nqgdwfnqbvavp1g61n8vbvyh1-wayland-1.23.0/lib/libwayland-server.so /nix/store/17ligilsrswqnrfdvv0al2mvqpvlcr96-pango-1.52.2/lib/libpangocairo-1.0.so /nix/store/17ligilsrswqnrfdvv0al2mvqpvlcr96-pango-1.52.2/lib/libpango-1.0.so /nix/store/lsrix2cqck6rcsshjpn4y6j9dysni78f-harfbuzz-9.0.0/lib/libharfbuzz.so /nix/store/rflkfhqh794nw7vgdzrg0lhjii6v3w8r-cairo-1.18.0/lib/libcairo.so /nix/store/fbs3ykc63n06yczp4bq3pr53g5l4crwx-pixman-0.43.4/lib/libpixman-1.so /nix/store/j7pclr7nq518ld7fhl1g79w4amdb4p2l-libXcursor-1.2.2/lib/libXcursor.so /nix/store/n2aif1mg86whm5ls99w33558whkyh4za-libdrm-2.4.122/lib/libdrm.so /nix/store/4h5k8gvvx52cwm1hlqvlaj6k6gmnqllb-libinput-1.26.1/lib/libinput.so /nix/store/hykhzxanlm463wpcw2546rp9ba8hjcz6-mesa-24.2.1/lib/libgbm.so /nix/store/d1jna110cihfr8024bgb504r5pvamrnv-glib-2.80.4/lib/libgio-2.0.so /nix/store/d1jna110cihfr8024bgb504r5pvamrnv-glib-2.80.4/lib/libgobject-2.0.so /nix/store/d1jna110cihfr8024bgb504r5pvamrnv-glib-2.80.4/lib/libglib-2.0.so /nix/store/8a0xnfn0d6xd6hhwarqqaaa42bap96by-hyprlang-0.5.2+date=2024-09-01_c12ab78/lib/libhyprlang.so /nix/store/cj5d1x363hkl5g2z3vdw9yf9kp4a4yw7-hyprcursor-0.1.9+date=2024-08-02_912d560-lib/lib/libhyprcursor.so /nix/store/gf5bjfck5c7sl4mdkbw8qawb3vw5xmyl-hyprutils-0.2.1+date=2024-08-29_8976e3f/lib/libhyprutils.so && :
hyprland> /nix/store/d828ccvc2148g7m49hh3mzvyzwpipy46-binutils-2.42/bin/ld: hyprpm/CMakeFiles/hyprpm.dir/src/core/PluginManager.cpp.o: in function `CPluginManager::headersValid()':
hyprland> /build/source/hyprpm/src/core/PluginManager.cpp:371:(.text+0x7cfb): undefined reference to `Hyprutils::String::trim(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)'
hyprland> /nix/store/d828ccvc2148g7m49hh3mzvyzwpipy46-binutils-2.42/bin/ld: hyprpm/CMakeFiles/hyprpm.dir/src/core/PluginManager.cpp.o: in function `CPluginManager::updateHeaders(bool)':
hyprland> /build/source/hyprpm/src/core/PluginManager.cpp:444:(.text+0x97cf): undefined reference to `Hyprutils::String::trim(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)'
hyprland> clang++: error: linker command failed with exit code 1 (use -v to see invocation) |
@yangyingchao, I tried this on Gentoo, but still get the same error as before (see build log: https://pastebin.com/GXGCnVDS). I'm on gcc-13 in general (gcc-14 is still unstable and I won't compile my whole system with an unstable compiler), but I tried compiling hyprland-0.43.0 with clang-18, which should work as clang aims to be compatible with gcc. I'm a bit stuck with this now, do you have any ideas what else I can try to work around this issue? Also, I agree with @RossComputerGuy, why not try the following to avoid using C++26 for now?
|
|
Thanks for your quick response. Your suggestion seems to make sense, but looking at Hyprland's dependencies I see things like glibc and cairo. If I recompile them with clang, I will probably cause more harm than good and end up having to compile everything that depends on them with clang as well. That's not really an option for me. Reverting the changes sounds like a good idea. Probably I could manually create a portage user patch for now. Doing that for the next two years seems to be a bit tedious though :D |
|
Ok, I have created a patch to revert the changes in #7219 (see: https://pastebin.com/fyaVL4Az). Like this it builds with clang-18. Maybe it would be possible to have a compile flag to turn these changes on and off for people like me who run into issues building according to the C++26 standard. Would that be an option, @vaxerski? |
|
no. Adding options to introduce bugs do not interest us. Hyprland builds just fine with gcc (arch, fedora, etc) and clang (freebsd) if your distro can't build it, wait for your distro to update whatever is out of date. |
Well maybe if we know what's going on with the bug then maybe we can find an alternative solution which allows for better compatibility.
Well from these multiple reports even with up to date compilers, it sounds like it doesn't build. Plus up to date compilers isn't the only thing which matters here. How the compilers are configured and the general environment has an effect. |
|
CI passes, and according to repology alpine, arch, nix, opensus, freebsd, gentoo, and many others can compile just fine, because they all have 0.43.0 in their repos. Figuring out an environment that allows apps to compile is the packager's job, not ours. According to cppreference: so both gcc14 (libstdc++) and clang18 (libc++) should be able to compile hyprland no problems. If your environment breaks them, that's on you, not me. |
|
Thanks for your quick answers, vaxerski and RossComputerGuy. Indeed, the problem does not seem to be an out of date compiler on my side. With clang-18.1.8, which is an up to date version, I cannot build with the changes made in #7219, but with them reverted it works just fine. Of course, it is important to fix these bugs, but if there is some other fix than the current one, it would help a lot. I really like hyprland a lot and appreciate your work on it and I do want to continue using it. |
|
Just because compilers have it with the latest version doesn't mean it should be used. C++26 is a new standard that isn't even finalized, yeah it works in CI but it really doesn't feel proper relying on functions from an unfinished spec. The solution I mentioned earlier of just using the posix functions for fd's is a better solution which keeps the previous level of compatibility. |
|
papers accepted for a standard don't get un-accepted. The spec will not change. Your argument is not valid. |
While that is true, wouldn't it still be better to stay with the previous level of compatibility if possible? Of course things should work according to the new standard, but in fact it does take time until everybody has caught up to that. I think it's a matter of being pragmatic. |
|
The problem isn't clang, the problem is either its integration with libstdcxx (gcc's libc) or libcxx (clang's libc). For some reason I can either have hl not compile due to the missing native_handle, or compile but fail to link due to compiler shenanigans unknown to me. |
|
That's not my point. It's not that it might get unacceptable, it's that compatibility and reliability isn't guaranteed. Plus not everyone is ready to compile with newer C++ stdlibs so why should distros have to be forced to get things working with a standard that isn't even complete for just 1 package? Plus it could be distros wont need any fixes and it's just the compilers themselves that need more work. |
|
we've always targeted recent C++ features as they come out and we find them useful. Catching up is the package maintainers' job. If they don't want to, they don't have to package hyprland. As we can see, almost all distros that package hyprland have no problem with this. |
|
C++23 is recent and is supported by most distros, C++26 isn't. It might not even be considered a standard yet because it hasn't been finished. |
|
we started using C++23 back in '21 (or early '22, forgot) |
|
Adopting a new standard is a lengthy process and even C++20 (gcc status, clang status) and C++23 (gcc status, clang status) only have partial or experimental support in the most recent versions of gcc and clang. Even if one only uses the features which are already supported, it is not advisable to build on these features in production. From the GCC-14 manpage:
This being said, I think that @yangyingchao is right in saying the following:
According to the clang manual, the system's default stdlib is used, if not specified otherwise. By adding @vaxerski, I think you are right in saying that it is a distro specific problem, caused by the settings on my (or our) side. Probably it is just a matter of finding the right compiler and linker flags. If you could assist us, who have problems with that, it would be very kind. I have the following environment variables set, when compiling with clang-18.1.8: @yangyingchao, you said you were able to build hyprland with clang-18, right? Do your flags differ from mine in any relevant way? |
|
the linker error looks like you linked hyprutils with a different stdlib / compiler than the one you built hl with. They have to match for all hypr* deps (including aq) |
In Nixpkgs, we only support using GCC's C++ stdlibs in the Linux stdenv. However, we do have an experimental |
Yes, I also thought so. I did recompile |
|
no clue then
then compile hyprland with gcc, problem solved |
That doesn't solve this problem for everyone. For example, @g-regex mentioned this earlier:
Like I mentioned multiple times, just use posix methods for this until C++26 is fully standardized and no longer experimental in compilers. |
|
that won't happen. You can hold off hyprland updates until you see them fit. |
Not exactly the same, mine is simpler: I just set But I think your flags should be OK.
It seems that In my case, I recompiled |
|
Thank you, @yangyingchao, for your help. Rebuilding However, now my hy3 plugin stopped working - even after rebuilding it. I don't know which compiler hyprpm uses (probably my system default, gcc-13). Of course I could also build hy3 manually, but I find updating hyprland and then separately updating the plugins via hyprpm already painful, so this cannot be a long term solution. (But enough of the hy3 issues, before this becomes offtopic). I'll try installing gcc-14 in a separate slot now and recompile the whole list of hyprland dependencies again with gcc-14 and hope that that works. |
|
generally it's not recommended to mix C++ compilers / stdlibs on one system, due to issues like these. stdlib ABIs are not compatible between them, so everything that relies on them must be recompiled with the same stdlib and compiler. Ideally also the same version, though at least for gcc's stdlibc++ I don't think they break ABI that often...? |
Thanks for the heads up. I would of course prefer not to, but - as I mentioned - I will not compile my whole system with an unstable compiler (
I installed Just out of curiosity: @yangyingchao, I suppose your default compiler is |
|
Is it even possible to compile any plugins with clang, as it doesn't support the |
yes |
|
For anybody interested for a fix. Update your lipzip (some distros have it outdated) and compile all hyprland related packages with GCC, then mixed compilers aren’t a big deal and it just works. Enjoy |
|
I cannot reproduce this with... # ~ hyprctl plugin load /usr/lib64/Hyprspace.so
error in loading plugin, last error: Plugin /usr/lib64/Hyprspace.so could not be loaded: /usr/lib64/Hyprspace.so:
undefined symbol: _ZN5Debug3logE8LogLevelNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEWhat am i doing wrong? |
Regression?
Yes
System Info and Version
System/Version info
NixOS 24.11, but irrelevant
Description
Build fails with Clang. Happens on Clang 18, 19.
How to reproduce
Compile Hyprland on NixOS with clang.
On nix, you can just override
stdenv, setpkgs.clangStdenvorpkgs.llvmPackages.stdenv.Crash reports, logs, images, videos
The text was updated successfully, but these errors were encountered: