4 ms·

The issue I see most often is someone compiled the application on a slightly newer version of Linux and when they try to run it on a slightly older machine it b

The issue I see most often is someone compiled the application on a slightly newer version of Linux and when they try to run it on a slightly older machine it barfs saying that it needs GLIBC_2.31 and the system libc only has up to GLIBC_2.28 or something like that. Even if you aren't using anything that changed in the newer versions it will refuse to run.

account42 4y ago
> Even if you aren't using anything that changed in the newer versions it will refuse to run. Nope, versioning is on a per symbol basis so if that prevents you from running the program it is actually using a symbol (i.e. function) that changed.
LtWorf 4y ago
That is not a bug. Just make a chroot with an older glibc and build there if you want to link against an older glibc. That easy. It works with future versions, not with past versions.
- jandrese 4y ago
  That only works if you're the person who compiled the application. A recent example where I ran into this: Cura 5.0+ won't run on Ubuntu 20 because the system libraries on Ubuntu 20 are too old.
- int_19h 4y ago
  That's an ergonomic deficiency. In practice, you probably need more than glibc, so then you have to make sure that other bits are available in this chroot. And if it so happens that one of the build tools that you rely on needs a newer version of glibc than the one you're building against, it still breaks down. On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
  - LtWorf 4y ago
    > That's an ergonomic deficiency. Do you build software on your desktop machine and ship it? Do you not build in a chroot (or container, how the cool kids call them nowadays) to make sure the build is actually using what you think it should be using? You have to build in a chroot or similar in any case. Just use the CORRECT one. > On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform. Except if you need a c++ redistributable… then you must ship the redistributable .exe setup inside your setup because windows. Let's not pretend shipping software on windows is easier. Anyway all of this only applies to proprietary software. For free sotware the distribution figures it all out, does automatic rebuilds if needed and so on. Really, just stick to free software, it's much easier.
    - int_19h 4y ago
      You don't need chroot to make sure that your build uses correct versions of all dependencies; you just need a sane build system that doesn't grab system-wide headers and libs. Setting up chroot is way overkill for this purpose; it's not something that should even require root. In case of Windows SDK, each version ships headers that are compatible going all the way back to Win9x, and you use #defines to select the subset that corresponds to the OS you're targeting. With respect to the C runtime, Windows has been shipping its equivalent of glibc as a builtin OS component for 7 years now. And prior to that, you could always statically link.
      - LtWorf 4y ago
        > Setting up chroot is way overkill for this purpose; debootstrap stable chrootdir That's it. Don't pretend it's difficult because it isn't.
jacooper 4y ago
Flatpak exists to solve this.
- jandrese 4y ago
  Flatpak throws the baby out with the bathwater though. For example, on Ubuntu 22 if you install Firefox and don't have snaps enabled it installs the Flatpak, but if you do it can't access ffmpeg in the system so you can't play a lot of video files. It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails.
  - tadfisher 4y ago
    > it can't access ffmpeg in the system so you can't play a lot of video files. That's a typical packaging bug. Libraries should be bundled in the build or specified as a runtime dependency. > It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails. All of this sucks and the user experience here needs a ton of work. I get the technical issues with co-mingling sandboxed and unsandboxed state, but there needs to be at least user-friendly options to migrate or share state with the sandbox. A replacement for the xdg-open/xdg-mime/gio unholy trinity that offers runtime extension points for sandboxes might be nice. Maybe I could write a prototype service.
    - jandrese 4y ago
      I think the issue with ffmpeg is that it needs to access GL driver libraries in order to support hardware acceleration. The GL libraries are dependent on your hardware and have to match what you have installed on the system. So you'd end up having to support a hundred different variations of Firefox flatpacks and users would have to make sure they match when installing, and remember to uninstall and reinstall when they update their graphics drivers.

account42 4y ago

> Even if you aren't using anything that changed in the newer versions it will refuse to run. Nope, versioning is on a per symbol basis so if that prevents you from running the program it is actually using a symbol (i.e. function) that changed.

LtWorf 4y ago

That is not a bug. Just make a chroot with an older glibc and build there if you want to link against an older glibc. That easy. It works with future versions, not with past versions.

jandrese 4y ago
That only works if you're the person who compiled the application. A recent example where I ran into this: Cura 5.0+ won't run on Ubuntu 20 because the system libraries on Ubuntu 20 are too old.
int_19h 4y ago
That's an ergonomic deficiency. In practice, you probably need more than glibc, so then you have to make sure that other bits are available in this chroot. And if it so happens that one of the build tools that you rely on needs a newer version of glibc than the one you're building against, it still breaks down. On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
- LtWorf 4y ago
  > That's an ergonomic deficiency. Do you build software on your desktop machine and ship it? Do you not build in a chroot (or container, how the cool kids call them nowadays) to make sure the build is actually using what you think it should be using? You have to build in a chroot or similar in any case. Just use the CORRECT one. > On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform. Except if you need a c++ redistributable… then you must ship the redistributable .exe setup inside your setup because windows. Let's not pretend shipping software on windows is easier. Anyway all of this only applies to proprietary software. For free sotware the distribution figures it all out, does automatic rebuilds if needed and so on. Really, just stick to free software, it's much easier.
  - int_19h 4y ago
    You don't need chroot to make sure that your build uses correct versions of all dependencies; you just need a sane build system that doesn't grab system-wide headers and libs. Setting up chroot is way overkill for this purpose; it's not something that should even require root. In case of Windows SDK, each version ships headers that are compatible going all the way back to Win9x, and you use #defines to select the subset that corresponds to the OS you're targeting. With respect to the C runtime, Windows has been shipping its equivalent of glibc as a builtin OS component for 7 years now. And prior to that, you could always statically link.
    - LtWorf 4y ago
      > Setting up chroot is way overkill for this purpose; debootstrap stable chrootdir That's it. Don't pretend it's difficult because it isn't.

jacooper 4y ago

Flatpak exists to solve this.

jandrese 4y ago
Flatpak throws the baby out with the bathwater though. For example, on Ubuntu 22 if you install Firefox and don't have snaps enabled it installs the Flatpak, but if you do it can't access ffmpeg in the system so you can't play a lot of video files. It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails.
- tadfisher 4y ago
  > it can't access ffmpeg in the system so you can't play a lot of video files. That's a typical packaging bug. Libraries should be bundled in the build or specified as a runtime dependency. > It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails. All of this sucks and the user experience here needs a ton of work. I get the technical issues with co-mingling sandboxed and unsandboxed state, but there needs to be at least user-friendly options to migrate or share state with the sandbox. A replacement for the xdg-open/xdg-mime/gio unholy trinity that offers runtime extension points for sandboxes might be nice. Maybe I could write a prototype service.
  - jandrese 4y ago
    I think the issue with ffmpeg is that it needs to access GL driver libraries in order to support hardware acceleration. The GL libraries are dependent on your hardware and have to match what you have installed on the system. So you'd end up having to support a hundred different variations of Firefox flatpacks and users would have to make sure they match when installing, and remember to uninstall and reinstall when they update their graphics drivers.