6 ms·

Now try building a "portable" binary that runs on a version of Linux older than yours.

by dataflow 4y ago

rocqua 4y ago
Isn't that simply a matter of targeting an older glibc? I am probably missing something though.
- dataflow 4y ago
  Yes, "simply". It's a very fun process. Around 100 times more fun than the onerous git config --global core.symlinks true
  - andrewmcwatters 4y ago
    Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.
    - Spivak 4y ago
      Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.
      - jeroenhd 4y ago
        It says a lot about Linux development that for cases like these "just install the Linux equivalent of Windows XP in a container and run the tools inside that" is an accepted solution. It's a solution that works well and is used by loads of developers, but it's still comically silly.
        account42 4y ago
        There are other approaches like https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against. Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.
      - rkeene2 4y ago
        You can also just cross-compile targeting whatever you want, including RHEL. I wrote a tool [0] which will take any system and create a cross-compiler toolchain for it, this is what I use to compile for Linux, HP-UX, Solaris, BSD, etc on Linux. [0] https://build-cc.rkeene.org/ https://build-cc.rkeene.org/
      - andrewmcwatters 4y ago
        I actually haven’t heard of this approach. Could you explain more or point me to some further reading if you read this and have a moment?
defen 4y ago
Use ‘zig cc’ and target the appropriate glibc.
- password4321 4y ago
  I was sad to find out "Zig supports only the last three macOS versions". No ncdu2 for me :( https://github.com/ziglang/zig/pull/10232#issue-1064864004 https://github.com/ziglang/zig/pull/10232#issue-1064864004
  - AndyKelley 4y ago
    Apple only supports the last three macOS versions too, so if you're on an older one than that you are not getting security vulnerability patches.
    - password4321 4y ago
      One of Zig's claims to fame is how widely supported/cross-platform their build tools are, and I had high hopes. But they don't publicize this limit of their macOS support -- I found out the hard way. I really appreciate how far MacPorts bends over backwards to keep things working. I love my ancient machine and have a few 32-bit apps I need, though I guess old hardware isn't quite the excuse it used to be. https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#macbook-air https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.ht...
      - AndyKelley 4y ago
        I'm interested in re-evaluating this policy once we get a bit further along in the project. It could work nicely given that we have OS version min/max as part of the target, available to inspect with conditional compilation. We get a lot of requests to support Windows all the way back to XP too, despite Microsoft's long-expired support. All this scope creep takes development efforts away from reaching 1.0 however. If we had more labor, then we could potentially take on more scope. And if we had more money then we could hire more labor. So if y'all want Zig to support a wider OS version range, we need some more funding.
hacker_homie 4y ago
Easy static link everything. I think you meant a GUI application that runs on a version of Linux older than yours.
- dataflow 4y ago
  Statically link everything? Including glibc?
  - melissalobos 4y ago
    > Including glibc? Any reasonable person doing this would use Musl of course.
    - tedunangst 4y ago
      And then you discover your program can't resolve hostnames because "DNS responses shouldn't be that big".
      - ducktective 4y ago
        Can you explain how musl is related to this DNS resolving problem?
        brettdong 4y ago
        https://news.ycombinator.com/item?id=28312935 https://news.ycombinator.com/item?id=28312935
      - speed_spread 4y ago
        But honestly, they really shouldn't.
  - ajvs 4y ago
    AppImage is sufficient.
xvilka 4y ago
Compile with Musl inside Alpine container.
Starlevel001 4y ago
Compile in an old Debian version docker container.
Arnavion 4y ago
If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs /usr/lib64 vs /usr/lib/x86_64-linux-gnu/ vs...), and different compile-time configuration (eg openssl engines directory) across distros.
- worewood 4y ago
  > If you want to build binaries for a distro, build in that distro. > Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. This is why Windows, with all its issues, is still relevant in 2022. I got tired of updating my distro and software stopping to work. If you are on happy walled garden land of the main repository you're fine. When you need some specialized software or something that is not being maintained anymore, good luck. And at the end of the day, people just want their work done. This is why Windows with all bloat, advertising, tracking, security issues (no click RCE in 2022, wtf) STILL is going strong.
- criddell 4y ago
  CentOS 7 is from 2014. That isn’t very old.
  - Arnavion 4y ago
    It has a few old things unique to it in our support matrix. It's the only distro with openssl 1.0 so a bunch of API and related things are different. It's also the only distro where systemd socket activation doesn't work if your service has more than one socket, because its version of systemd predates the LISTEN_FDNAMES env var. Also, it is old enough that it's going out of LTS soon.
  - faho 4y ago
    CentOS 7 may have been released in 2014, but the software it shipped was already quite old then. As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9 https://repology.org/repository/centos_stream_9. Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009). [0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.
hackernudes 4y ago
I totally agree, it's practically impossible. Is it a philosophical thing or a technological thing? GPL is about source code and going against that will never make much progress. It is almost always possible to do some relatively simple hacks to make old stuff work, though (LD_PRELOAD, binfmt_misc/qemu, chroot/docker).
anonymoushn 4y ago
ok: `zig build -Dtarget=native-native-musl -Drelease-fast=true` This is portable to CPUs with the same features running older linuxes. To be portable to CPUs with fewer features you should specify the CPU family with `-Dcpu=foo_bar` which seems to be the equivalent of `-march=foo-bar`.
Shorel 4y ago
The most stable Linux ABI is Win32 =)
seba_dos1 4y ago
Not that hard. Since it's not a use case that most GNU/Linux software needs to be concerned about it's easy to make mistakes and resources are scarce, but once you know what you're doing it's usually not a big deal (maybe except of some specific edge cases). There's lots of old games on Steam that still work on modern distros and new games that work on older ones (and, of course, there's a lot of them that's broken too - but these days it takes only a few clicks to simply run them in a container and call it a day).
- nickelpro 4y ago
  It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows. On Linux Steam distributes an entire runtime environment based on an ancient Ubuntu release exactly to circumvent this problem. Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and lots of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible. [1]: https://github.com/pypa/manylinux https://github.com/pypa/manylinux
  - seba_dos1 4y ago
    Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top notch, images with old distros are one command away, testing is easy; in practice I had much more trouble compiling stuff for Windows than for old GNU/Linux distros.
    - nickelpro 4y ago
      It's easy to compile an entirely new binary for every platform/distro, and it's easy to bundle an entire execution environment along with a single binary using docker, what's hard is compiling a single binary and have it run across all distros and execution environments.
account42 4y ago
Does having a sysroot with an older glibc count? https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev

Now try building a "portable" binary that runs on a version of Linux older than yours.

rocqua 4y ago

Isn't that simply a matter of targeting an older glibc? I am probably missing something though.

dataflow 4y ago
Yes, "simply". It's a very fun process. Around 100 times more fun than the onerous git config --global core.symlinks true
- andrewmcwatters 4y ago
  Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.
  - Spivak 4y ago
    Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.
    - jeroenhd 4y ago
      It says a lot about Linux development that for cases like these "just install the Linux equivalent of Windows XP in a container and run the tools inside that" is an accepted solution. It's a solution that works well and is used by loads of developers, but it's still comically silly.
      - account42 4y ago
        There are other approaches like https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against. Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.
    - rkeene2 4y ago
      You can also just cross-compile targeting whatever you want, including RHEL. I wrote a tool [0] which will take any system and create a cross-compiler toolchain for it, this is what I use to compile for Linux, HP-UX, Solaris, BSD, etc on Linux. [0] https://build-cc.rkeene.org/ https://build-cc.rkeene.org/
    - andrewmcwatters 4y ago
      I actually haven’t heard of this approach. Could you explain more or point me to some further reading if you read this and have a moment?

defen 4y ago

Use ‘zig cc’ and target the appropriate glibc.

password4321 4y ago
I was sad to find out "Zig supports only the last three macOS versions". No ncdu2 for me :( https://github.com/ziglang/zig/pull/10232#issue-1064864004 https://github.com/ziglang/zig/pull/10232#issue-1064864004
- AndyKelley 4y ago
  Apple only supports the last three macOS versions too, so if you're on an older one than that you are not getting security vulnerability patches.
  - password4321 4y ago
    One of Zig's claims to fame is how widely supported/cross-platform their build tools are, and I had high hopes. But they don't publicize this limit of their macOS support -- I found out the hard way. I really appreciate how far MacPorts bends over backwards to keep things working. I love my ancient machine and have a few 32-bit apps I need, though I guess old hardware isn't quite the excuse it used to be. https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#macbook-air https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.ht...
    - AndyKelley 4y ago
      I'm interested in re-evaluating this policy once we get a bit further along in the project. It could work nicely given that we have OS version min/max as part of the target, available to inspect with conditional compilation. We get a lot of requests to support Windows all the way back to XP too, despite Microsoft's long-expired support. All this scope creep takes development efforts away from reaching 1.0 however. If we had more labor, then we could potentially take on more scope. And if we had more money then we could hire more labor. So if y'all want Zig to support a wider OS version range, we need some more funding.

hacker_homie 4y ago

Easy static link everything. I think you meant a GUI application that runs on a version of Linux older than yours.

dataflow 4y ago
Statically link everything? Including glibc?
- melissalobos 4y ago
  > Including glibc? Any reasonable person doing this would use Musl of course.
  - tedunangst 4y ago
    And then you discover your program can't resolve hostnames because "DNS responses shouldn't be that big".
    - ducktective 4y ago
      Can you explain how musl is related to this DNS resolving problem?
      - brettdong 4y ago
        https://news.ycombinator.com/item?id=28312935 https://news.ycombinator.com/item?id=28312935
    - speed_spread 4y ago
      But honestly, they really shouldn't.
- ajvs 4y ago
  AppImage is sufficient.

xvilka 4y ago

Compile with Musl inside Alpine container.

Starlevel001 4y ago

Compile in an old Debian version docker container.

Arnavion 4y ago

If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs /usr/lib64 vs /usr/lib/x86_64-linux-gnu/ vs...), and different compile-time configuration (eg openssl engines directory) across distros.

worewood 4y ago
> If you want to build binaries for a distro, build in that distro. > Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. This is why Windows, with all its issues, is still relevant in 2022. I got tired of updating my distro and software stopping to work. If you are on happy walled garden land of the main repository you're fine. When you need some specialized software or something that is not being maintained anymore, good luck. And at the end of the day, people just want their work done. This is why Windows with all bloat, advertising, tracking, security issues (no click RCE in 2022, wtf) STILL is going strong.
criddell 4y ago
CentOS 7 is from 2014. That isn’t very old.
- Arnavion 4y ago
  It has a few old things unique to it in our support matrix. It's the only distro with openssl 1.0 so a bunch of API and related things are different. It's also the only distro where systemd socket activation doesn't work if your service has more than one socket, because its version of systemd predates the LISTEN_FDNAMES env var. Also, it is old enough that it's going out of LTS soon.
- faho 4y ago
  CentOS 7 may have been released in 2014, but the software it shipped was already quite old then. As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9 https://repology.org/repository/centos_stream_9. Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009). [0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.

hackernudes 4y ago

I totally agree, it's practically impossible. Is it a philosophical thing or a technological thing? GPL is about source code and going against that will never make much progress. It is almost always possible to do some relatively simple hacks to make old stuff work, though (LD_PRELOAD, binfmt_misc/qemu, chroot/docker).

anonymoushn 4y ago

ok: `zig build -Dtarget=native-native-musl -Drelease-fast=true` This is portable to CPUs with the same features running older linuxes. To be portable to CPUs with fewer features you should specify the CPU family with `-Dcpu=foo_bar` which seems to be the equivalent of `-march=foo-bar`.

Shorel 4y ago

The most stable Linux ABI is Win32 =)

seba_dos1 4y ago

Not that hard. Since it's not a use case that most GNU/Linux software needs to be concerned about it's easy to make mistakes and resources are scarce, but once you know what you're doing it's usually not a big deal (maybe except of some specific edge cases). There's lots of old games on Steam that still work on modern distros and new games that work on older ones (and, of course, there's a lot of them that's broken too - but these days it takes only a few clicks to simply run them in a container and call it a day).

nickelpro 4y ago
It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows. On Linux Steam distributes an entire runtime environment based on an ancient Ubuntu release exactly to circumvent this problem. Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and lots of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible. [1]: https://github.com/pypa/manylinux https://github.com/pypa/manylinux
- seba_dos1 4y ago
  Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top notch, images with old distros are one command away, testing is easy; in practice I had much more trouble compiling stuff for Windows than for old GNU/Linux distros.
  - nickelpro 4y ago
    It's easy to compile an entirely new binary for every platform/distro, and it's easy to bundle an entire execution environment along with a single binary using docker, what's hard is compiling a single binary and have it run across all distros and execution environments.

account42 4y ago

Does having a sysroot with an older glibc count? https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev