Build tools unavailable with Ubuntu #10604
Replies: 4 comments 1 reply
-
|
Note that it is possible to continue using the newer C++23
These provide equivalent semantics, but they are used in different contexts — that is, anything you can write with one feature set can be refactored using the other feature set. The issue with the changes as-is is that they depend on feature set So the two obvious ways to fix this in my mind are:
The original PR was closed because the approvers ignored the perfectly valid failure reported by CI. And by doing so, they have rendered this project extremely inaccessible to (arguably) the most widely-adopted Linux desktop environment. But whyI'm still not sure why the changes were even merged in the first place. There is no evidence that they support a new feature, improve performance, fix a bug, or enhance the software in any way. The only effect of this change is that it breaks compatibility with standard/default toolchains found in many popular Linux distributions. |
Beta Was this translation helpful? Give feedback.
-
|
Why? Because that's how we develop. If GCC and Clang support a feature, we use it. We wait for major up-to-date desktop distros to have our needed versions and then don't care. Arch - 15.1.1 Keeping your compiler up to date is important if a distro wants to be taken seriously. GCC 15 is months old. We do not give a shit about Debian / Ubuntu, in reality. These distros are perpetually, laughably outdated. "Stable" to a point of unusability. This change does not improve performance - yes, but so what? We also make changes that do fix real problems that rely on new gcc. The real reason is we don't check at all whether debian's gcc 11 or whatever the hell they have in their repos is up-to-date enough, because our entire ecosystem depends on dependencies too new for debian anyways (w-p, libinput, wl, libdrm, etc) Realistically, if Arch + Fedora + Nix have gcc x and clang y that we want for some feature, we'll use it. Truth is - You're on an OS that's a relic of the past and does its users a disservice - and we do not support it. |
Beta Was this translation helpful? Give feedback.
-
|
Even if I were running the exact same distro as you, the fact remains it is an irresponsible decision at best to force-merge a breaking change with zero conceivable benefit. The only impact of the change is that it breaks compatibility with distros identified in your own documentation. Your own CI tried to warn you of this. |
Beta Was this translation helpful? Give feedback.
-
|
I find this behavior "strange", too. |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth to anyone stumbling upon this thread, if compiling with clang-20 and looking for a quick and dirty fix to avoid migrating to a new distro on a Monday: diff --git a/hyprctl/main.cpp b/hyprctl/main.cpp
index daf8d4a8..e9dc8fa1 100644
--- a/hyprctl/main.cpp
+++ b/hyprctl/main.cpp
@@ -268,7 +268,7 @@ int requestIPC(std::string_view filename, std::string_view arg) {
sockaddr_un serverAddress = {0};
serverAddress.sun_family = AF_UNIX;
- std::string socketPath = getRuntimeDir() + "/" + instanceSignature + "/" + filename;
+ std::string socketPath = getRuntimeDir() + "/" + instanceSignature + "/" + std::string(filename);
strncpy(serverAddress.sun_path, socketPath.c_str(), sizeof(serverAddress.sun_path) - 1);
diff --git a/src/helpers/Monitor.cpp b/src/helpers/Monitor.cpp
index 4e5c4080..1944f22e 100644
--- a/src/helpers/Monitor.cpp
+++ b/src/helpers/Monitor.cpp
@@ -549,7 +549,7 @@ bool CMonitor::applyMonitorRule(SMonitorRule* pMonitorRule, bool force) {
std::ranges::sort(sortedModes, sortFunc);
if (sortedModes.size() > 3)
sortedModes.erase(sortedModes.begin() + 3, sortedModes.end());
- requestedModes.insert_range(requestedModes.end(), sortedModes | std::views::reverse);
+ requestedModes.insert(requestedModes.end(), sortedModes.rbegin(), sortedModes.rend());
};
// last fallback is always preferred mode |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
https://wiki.hyprland.org/Getting-Started/Installation/#installation
OK, so, https://wiki.hyprland.org/Getting-Started/Installation/#packages, select Ubuntu:
😕
So I proceed to build the entire ecosystem myself, using the latest revision of all default branches. Absolutely no issues building, linking, installing. Great work.
Now, finally, on to build Hyprland:
The error was introduced with 9190443. The PR referenced in its comment has discussion about this failing to build on NixOS as well.
Following that trail, it turns out this changes forces Hyprland to now require GCC 15 or newer(!).
This seems rather aggressive, since there exists precisely one Ubuntu release that even has gcc-15 available in any official repo (main, universe, or multiverse), and that's the absolute latest, bleeding edge Ubuntu release (from Apr 2025). There are zero LTS releases that have gcc-15 available.
So, currently, the only way to install Hyprland on 95% of Ubuntu desktops is to:
Do the changes linked above really warrant such extreme breakage?
Full build output
Beta Was this translation helpful? Give feedback.
All reactions