| ▲ | simonask 2 hours ago |
| It is a testament to the complete failure of the GNU/Linux userland that something like this seems at all attractive to spend time on (or, it seems, LLM tokens). Actually, scratch that, because Windows and macOS have historically struggled with ABI compatibility as well (macOS less so, due to not caring about backward compatibility in the first place). How did we get to the point where people feel they need to go to the length of embedding an ELF loader in their binary (!!) rather than just linking with glibc? |
|
| ▲ | diabllicseagull an hour ago | parent | next [-] |
| I'm mostly taken aback all the solutions devised to go around the issue, especially the container-based ones. I really disliked it when I grabbed the flatpak version of Blender only to find out that it can't have HIP support. (they might have fixed it by now but you get the point) |
|
| ▲ | wmf 27 minutes ago | parent | prev | next [-] |
| Linux loves to leave papercuts unfixed or undocumented for decades. The solution is to build against an older version of glibc but no one tells you that or how to do it. |
| |
| ▲ | emidoots 6 minutes ago | parent | next [-] | | Luckily Zig makes this quite easy to do. In Mach[0] we are able to just `zig build -Dtarget=x86_64-linux-gnu.2.28` to build GUI apps against an ~8 year old glibc version for maximum compatibility. This is possible because Zig allows for targeting most glibc versions out of the box with its cross-compilation support. [0] https://machengine.org | |
| ▲ | pg83 18 minutes ago | parent | prev [-] | | It's a pretty poor solution, to be honest. 1) Why should I limit myself to the available APIs? 2) Not just glibc. For example, if I build against the latest libstdc++, it will automatically support the more recent glibc. And pinning the old libstdc++ -well, that's just not a good idea. |
|
|
| ▲ | pg83 2 hours ago | parent | prev [-] |
| Glibc has a terrible history of binary incompatibility. If that's so hard to believe, try running binaries built on one distribution on other distributions. Linux has two stable ABIs: the kernel ABI for static programs, and, ironically, WINE. |
| |
| ▲ | vlovich123 an hour ago | parent | next [-] | | I haven’t heard of this and I don’t think you’re right. Glibc, for all its faults, as a general rule does backward compatibility well. The problem is if you compile against a newer glibc (common in CI by default) and try to run on a distro with an older (common in the wild). If your CI uses an older glibc you should be fine AFAIK. | | |
| ▲ | pg83 an hour ago | parent [-] | | https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most "famous" example. There are also much less well-known "little things" that regularly pop up here and there. > If your CI uses an older glibc you should be fine AFAIK. In any case, my binaries work not only under glibc, but also under Alpine, and (work in progress) under android/bionic. | | |
| ▲ | vlovich123 3 minutes ago | parent [-] | | Not sure what you’re trying to show with that bug report but it’s not a case of cross distro glibc issues. If I read correctly it’s a vanilla behavioral change that exposed preexisting UB in flash. Not sure how the comments about alpine or bionic relate either to my claim that cross distro glibc is fine. |
|
| |
| ▲ | diabllicseagull an hour ago | parent | prev [-] | | according to appimage recommendations as long as you build against glibc with an earlier version than the system it's run on it should be fine. https://docs.appimage.org/reference/best-practices.html I hear you about WINE though. | | |
|
