@lanodan reminds me of a recent change to iso C where musl was one of very few conforming implementations so they changed the spec so now it's one of the few that isnt (see printf %lc in november on musl ml)
posix should really change this too but sadly it's an abi break
@lanodan yeah, anyway it's recompiling everything from scratch on every breaking update. :)
which by itself isn't bad but it just contradicts my belief that library developers (or in general whose work others rely on) should at least try keeping backwards compatibility. And of course compatibility with alternative implementations, even if it breaks an imaginary standard.
With musl? Absolutely. They said they won't even try keep compatibility. New breaking musl update? Go recompile everything and probably lose some software that's impossible or rather hard to rebuild.
Honestly, can't think of a libc that do keeps it's ABI stable except Bionic which breakages are usually documented.
@a1ba Linux binaries is either you can make static binaries or you're completely and forever screwed and for an abysmal number of reasons, one of which being that APIs are defined by C, which isn't appropriate for defining ABIs.
Everyone learnt this one, specially non-C developers like anyone who would use Go or Java.
Meaning you tried to do something that no one should ever do, you did it, got burned and instead of learning you're blaming everyone else and harassing anything anyone dealing with anything somewhat related to musl.
@lanodan I once tried the simplest on first glance thing: compile my own free and open software targeting all actual versions of various Linux distros, just to let users install a package using their distro package management.
That was my worst nightmare.
1) It's not easy to keep up with whatever every distro has. <--- which is where I have my grudge against everything that's not Portage... I kinda miss my Gentoo days :(
2) It's possible to make portable binaries but not always, something unexpectedly breaks anyway and it's always some tradeoff on a toolchain side. <--- which is where I have my main grudge against musl which doesn't even want to keep compatibility
3) It's possible to "bring your own distro" but it's also not flawless and overly bloated like Flatpak.
4) It's much easier to make building as simple as possible and instruct users on what to do <-- which is where I have my grudge against hard to maintain build systems like cmake and autotools
@a1ba Yet musl is the only one you see as a target for harassements and insults.
And I'm not saying it's not a case that could be worth pursuing, but if you want that to happen it's with pretty much the entirety of the linux userspace you'd effectively be making your own OS.
You can't always just build your program statically and expect it will work. Try to draw a triangle with OpenGL in a statically linked program without assuming the GL_VENDOR. With hardware acceleration. Just the simplest hello world. Doesn't sound like a thing "no one should ever do", isn't it?
Also, tell me, why keeping the ABI works for Windows? Ok, Windows must die, another example. Android! Why you can compile your C code targetting oldest Android version and it will work on every version released after?
@psykose I think I got it and it would mean linux-ABI wise musl is wrong, which I guess would overrule POSIX. (And codebases could use `#ifdef __linux__` if any Unix somehow is POSIX-conforming)
@lanodan@psykose That's the syscall not the function. There is no "linux ABI" governing the function. Assuming the function is nonconforming because the kernel is linux is wrong. Either write code not to care, or probe it with a configure test, or probe it with _Generic.
Arguably this is a case where "POSIX is wrong", but changing it would be breaking our own existing ABI to meet other-libc ones we have no obligation to match, so it's probably not a good idea to change..
@a1ba I've no idea how Android deals with ABIs, last time I tried to touch Android development was in Gingerbread era and I don't intend to touch Android ever again even as a user.
But well Google can be like "This is the ABI, anything else is banned" because they control and certify the platform, there's no alternatives, Nvidia's bullshit with EGLStream for example probably simply doesn't happens. (Meanwhile I wouldn't be surprised that you'd strongly defend nvidia's bullshit on ~desktop linux)
@lanodan you didn't answered the question. Why it works with Android? How this case is invalid?
Also yeah, you're right, maybe I want too much from musl that's not designed to keep backwards compatibility. They have the right to make a libc in a way they want.
Still, I find their decisions not fair to whoever that has to deal with them. Murder me for that.
Talking about libc, they also allow to bring newer libc version but still work with other system libraries. So you potentially might have a C23 on Windows XP. (I wonder if subsystem option works on latest MSVC)