4 ms·

> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an

> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers. Got it. So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. I'm pretty sure the principle of engineering design is to make things work in the face of incompetence by others. And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Whereas on Mac & Windows it's pretty easy to build applications on my up-to-date system targeting older variants.

skissane 2y ago
> And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Isn’t this easily solved by building in a container? Something a lot of people do anyway - I do it all the time because it insulates the build from changes in the underlying build agents - if the CI team decides to upgrade the build agent OS to a new release next month or migrate them to a different distro, building in a container (mostly) isolates my build job from that change, doing it directly on the agents exposes it to them
- vlovich123 2y ago
  Umm... that doesn't isolate you in any meaningful way because you're surrounding OS is still the container with a base image from Linux years ago?
einpoklum 2y ago
> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. But it is working, actually: * If you update your distro with binaries from apt, yum, zypper etc. - they work. * If you download statically-linked binaries - they work. * If you download Snaps/Flatpak, they work. > it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Only if you want to distribute a dynamically-linked binary without its dependencies. And even then - you have to build with a toolchain for that distro, not with that distro itself.
- vlovich123 2y ago
  > Only if you want to distribute a dynamically-linked binary Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively hostile to making it easy to distribute software to your platform is a compounding factor). I really dislike snaps/flat pack as they’re distro specific and overkill if I’m statically linking and my only dynamic dependency is glibc.
  - int_19h 2y ago
    Flatpaks aren't distro specific. As for being overkill, surely you can see the advantage of having a single uniform distribution format from the end user's perspective? Which, sure, might be overkill for your case (although app isolation isn't just about dependencies), but the important thing is that it is a working solution that you can use, and users only need to know how to install and manage them.
    - vlovich123 2y ago
      You have to install the flat pack runtime to begin with so that’s one obstacle for distribution. And it also doesn’t really isolate as much as you’d like to believe - eg dealing with audio will still be a mess because there’s like 4 different major audio interfaces. And now I have to host a flat pack repo and get the user to add my repo if it’s proprietary software. It’s really nowhere near as smooth and simple as on Windows/Mac/Android/ios.
GoblinSlayer 2y ago
Windows toolchain (even gnu) just provides old libraries to link with. This should work the same on linux, and AFAIK zig does just that.
- vlovich123 2y ago
  Yeah maybe I should just be complaining that the Rust tool chain (or rather distros) should be including old versions of prebuilt glibc to link against?
- int_19h 2y ago
  Windows toolchain provides the import libraries to link with, and these are basically just tables mapping function names to indices in the DLL export table. So long as you don't actually use the new functions, an app linked against a modern Windows SDK will run just fine on old Windows, unlike the situation with glibc.
  - GoblinSlayer 2y ago
    The situation with glibc is the same, you only depend on functions you use.
    - account42 2y ago
      Almost - with glibc your code uses functions like memcpy but you end up linking against symbols like memcpy@GLIBC_2.14 which is the version of memcpy added in glibc 2.14 and which won't be present in older versions. Which symbol version your calls use depends on the glibc version you build against - generally it's the most recent version of that particular function. For the Win32 this is rarely the case and instead you have to explicitly opt in to newer functions with fixed semantics. Still, to reliably target older Windows versions you need to tell your toolchain what to target. The Windows SDK also lets you specify the Windows version you want to target via WINVER / _WIN32_WINNT macros which make it harder to accidentally use unsupported functions. Similarly, the compilers and linkers for Windows have options to specify the minimum Windows version recorded in the final binary and which libraries to link against (classic win32 dlls or ucrt). Unfortunately there is no such mechanism to specify target version for glibc/gcc and you have you either build against older glibc versions or rely on third-party headers. Both solutions are workable and allow you to create binaries with a wide range of glibc version compatibility but they are not as ideal as direct support in the toolchain would be.

skissane 2y ago

> And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Isn’t this easily solved by building in a container? Something a lot of people do anyway - I do it all the time because it insulates the build from changes in the underlying build agents - if the CI team decides to upgrade the build agent OS to a new release next month or migrate them to a different distro, building in a container (mostly) isolates my build job from that change, doing it directly on the agents exposes it to them

vlovich123 2y ago
Umm... that doesn't isolate you in any meaningful way because you're surrounding OS is still the container with a base image from Linux years ago?

einpoklum 2y ago

> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. But it is working, actually: * If you update your distro with binaries from apt, yum, zypper etc. - they work. * If you download statically-linked binaries - they work. * If you download Snaps/Flatpak, they work. > it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Only if you want to distribute a dynamically-linked binary without its dependencies. And even then - you have to build with a toolchain for that distro, not with that distro itself.

vlovich123 2y ago
> Only if you want to distribute a dynamically-linked binary Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively hostile to making it easy to distribute software to your platform is a compounding factor). I really dislike snaps/flat pack as they’re distro specific and overkill if I’m statically linking and my only dynamic dependency is glibc.
- int_19h 2y ago
  Flatpaks aren't distro specific. As for being overkill, surely you can see the advantage of having a single uniform distribution format from the end user's perspective? Which, sure, might be overkill for your case (although app isolation isn't just about dependencies), but the important thing is that it is a working solution that you can use, and users only need to know how to install and manage them.
  - vlovich123 2y ago
    You have to install the flat pack runtime to begin with so that’s one obstacle for distribution. And it also doesn’t really isolate as much as you’d like to believe - eg dealing with audio will still be a mess because there’s like 4 different major audio interfaces. And now I have to host a flat pack repo and get the user to add my repo if it’s proprietary software. It’s really nowhere near as smooth and simple as on Windows/Mac/Android/ios.

GoblinSlayer 2y ago

Windows toolchain (even gnu) just provides old libraries to link with. This should work the same on linux, and AFAIK zig does just that.

vlovich123 2y ago
Yeah maybe I should just be complaining that the Rust tool chain (or rather distros) should be including old versions of prebuilt glibc to link against?
int_19h 2y ago
Windows toolchain provides the import libraries to link with, and these are basically just tables mapping function names to indices in the DLL export table. So long as you don't actually use the new functions, an app linked against a modern Windows SDK will run just fine on old Windows, unlike the situation with glibc.
- GoblinSlayer 2y ago
  The situation with glibc is the same, you only depend on functions you use.
  - account42 2y ago
    Almost - with glibc your code uses functions like memcpy but you end up linking against symbols like memcpy@GLIBC_2.14 which is the version of memcpy added in glibc 2.14 and which won't be present in older versions. Which symbol version your calls use depends on the glibc version you build against - generally it's the most recent version of that particular function. For the Win32 this is rarely the case and instead you have to explicitly opt in to newer functions with fixed semantics. Still, to reliably target older Windows versions you need to tell your toolchain what to target. The Windows SDK also lets you specify the Windows version you want to target via WINVER / _WIN32_WINNT macros which make it harder to accidentally use unsupported functions. Similarly, the compilers and linkers for Windows have options to specify the minimum Windows version recorded in the final binary and which libraries to link against (classic win32 dlls or ucrt). Unfortunately there is no such mechanism to specify target version for glibc/gcc and you have you either build against older glibc versions or rely on third-party headers. Both solutions are workable and allow you to create binaries with a wide range of glibc version compatibility but they are not as ideal as direct support in the toolchain would be.