7 ms·

How to create portable Linux binaries

114 points by synergy20 4y ago

qbasic_forever 4y ago
IMHO this is kind of silly to use very old versions of gcc, libc, etc. Instead use the kernel's namespacing, chroot, etc. features to ship your dependencies. I.e. build a flatpak and forget all these archaic tricks and machinations.
- FooBarWidget 4y ago
  Not all of your users can, or are willing to accept, container-like packages.
  - qbasic_forever 4y ago
    It's 2023, these features have been in the kernel for over a decade.
    - smoldesu 4y ago
      Can Flatpak package system services yet?
      - qbasic_forever 4y ago
        I don't think flatpak was designed or intended for services. What service manager will it depend on? It sounds like you probably want systemd portable services: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/
        smoldesu 4y ago
        If Flatpak wasn't designed or intended for services, I fail to see how it can be recommended as a relevant tool. I get what you're saying about containerization, but Flatpak is as much of a 'solution' to package management as a cork in a bullet wound.
      - jeroenhd 4y ago
        CoreOS (not specifically Fedora CoreOS) used to do that with Docker. I believe the OS ran your standard systemd services and all through interconnected containers. As far as I can tell, the project has been abandoned, though. I don't think Flatpak is the right tool for the job, it's clearly optimized for UI tools and the occasional command line invocation. Snap may be better for composing a working systems, though that comes with the obvious Snap downsides. Systemd has some great tools to accomplish image/container based operating systems, though I'm not sure how common it's used.
  - Xelynega 4y ago
    Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't want the container, they can typically compile the source too.
    - Dalewyn 4y ago
      Windows executables are not containers, both in the technical and laymen sense.
    - jeroenhd 4y ago
      Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.
    - badsectoracula 4y ago
      That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).
- badsectoracula 4y ago
  Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png
  - Vogtinator 4y ago
    > (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.
    - badsectoracula 4y ago
      Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
    - robertlagrant 4y ago
- jvanderbot 4y ago
  Or, you know, build with three tool chains: arm, windows x64, and Linux gnu x64 and get 90% of your users. Static complied dependencies goes a long way.
  - qbasic_forever 4y ago
    No like the post mentions you need to target a libc your users have on their system, which they show is best handled by linking to one that's a decade plus old (as a least common denominator most likely to be available). If that sounds silly... then ship your libc and everything you depend on in a flatpak or similar contained system image.
  - AnIdiotOnTheNet 4y ago
    Build for Windows, get 90% of potential users. Many of them on Linux!
- PaulDavisThe1st 4y ago
  flatpak is basically useless for any context where the application is expected to load and execute arbitrary 3rd party shared libraries (aka "plugins"). This rules out most sophisticated audio applications.
  - jancsika 4y ago
    Are audio apps the only type of app to use the plugin pattern? I've never seen any other app category mentioned when plugins (or an equivalent descriptor) come up. Does dl_open crash if it can't find an open ALSA connection or something?
    - PaulDavisThe1st 4y ago
      dlopen("plugin.so"); /* Load that super cool reverb plugin */ .... /* oops, the .so is not part of the flatpak ... fail */ Most other systems that do "plugins" tend to use a domain specific language and load the "plugin" as a normal file, rather than via the dynamic linker.
ThrowawayTestr 4y ago
I've always wondered why Linux binaries are incompatible with each other while you double click on an exe and it'll pretty much always work.
- zweifuss 4y ago
  Before Windows XP (2002) "DLL Hell" used to be a real problem too. Also a lot of current EXEs need at least Windows 7 SP1 to run.
- torstenvl 4y ago
  It will never truly be the year of the Linux desktop until this is fixed. Even assuming the developers of the major pieces of proprietary software were willing to put in the work to port, say, Photoshop or Word, packaging the result is made intentionally asinine. It's literally easier to run old Windows binaries on a Linux than to run old Linux binaries on Linux.
  - chungy 4y ago
    The problem is fixed: AppImage
    - okanat 4y ago
      Nope. They depend on fuse2 which isn't shipped with Opensuse which ships fuse3.
- Denvercoder9 4y ago
  Windows applications usually ship their own copy of all the libraries they use, instead of relying on the system copy of those libraries; and Microsoft is better at keeping system APIs backward-compatible (for some definition of system). Both approaches have advantages and disadvantages.
  - okanat 4y ago
    MS is almost perfect in this matter. You can still run Win 2k binaries. Most proper Windows applications do ship many libraries but they are often really special purpose or actually part of the application via plugin interfaces. On Windows you don't ship the equivalent of libc, libcurl, libssl, libX.. or SDL. You don't have to deal with any of the pains in the article. Those are all in the OS and they have a stable ABI. Moreover this approach makes your binaries more secure by updating more critical points of failure (i.e. web interfaces, crypto) with the OS rather than you as the developer being forced to do so.
timothine 4y ago
If you want to go even further, use something like this https://chromium.googlesource.com/linux-syscall-support https://chromium.googlesource.com/linux-syscall-support and compile statically. The syscall interface is stable enough that you can create binaries that will run against Linux kernels from decades ago, if needed.
- capableweb 4y ago
  If you want to go even further than that, you can use APE (αcτµαlly pδrταblε εxεcµταblε) which lets you compile a single binary that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD.
  - loupol 4y ago
    Cosmopolitan[0] is indeed worth mentioning here. It's an amazing project. [0] https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan
  - badsectoracula 4y ago
    Amusingly when i saw the title i assumed it'd be about APE :-P.
  - nashashmi 4y ago
    I miss QT web browser. It was a single binary that uses chrome engine.
- bjackman 4y ago
  Why not just statically link against a normal libc?
  - chungy 4y ago
    That's basically musl, and yes, that is the better idea.
  - edflsafoiewq 4y ago
    The article explains > Don’t try to statically link libc or libstdc++, this may cause trouble with other system libs you’ll use (because the system libs dynamically link libc and maybe libstdc++ - probably in versions different from what you linked statically. That causes conflicts.)
urbandw311er 4y ago
What an absolute convoluted nightmare.
no_time 4y ago
How about forgetting glibc alltogether and statically linking musl?
- flatiron 4y ago
  Can you explain the glibc hate? Been using it for 20+ years and really confused why people dislike it.
  - atemerev 4y ago
    Because you won’t be able to run your program on a HPC cluster that runs CentOS 7 with an ancient glibc, if you wrote it in C++17 on your Fedora machine. Or basically anywhere else. It will be much easier with musl.
    - bluedino 4y ago
      This hits close to home. We have a handful of versions of GCC and library paths for this reason. ROCKS never upgraded to CentOS 8, new hardware support is becoming an issue, so moving to a new cluster manager and a newer Rocky/Alma/? has been a long time coming.
  - TheChaplain 4y ago
    Probably because of just that, it's old and not cool anymore.
    - deleted 4y ago
      [deleted]
  - squarefoot 4y ago
    I can't speak for other use cases, but trying a musl based distro on restricted hardware convinced me how good it is. Memory/storage consumption is reduced by a a lot compared to glibc, and it's damn fast. Now I try to run Alpine wherever I need compactness and simplicity.
  - 4y ago
EGreg 4y ago
Redbean server, no? Actually portable executables?
- EGreg 4y ago
  https://justine.lol/ape.html https://justine.lol/ape.html
jqpabc123 4y ago
Or you could simply recognize the obvious --- Linux is not oriented toward supporting binary compatibility beyond the most rudimentary level. Effort in this regard with any app of substance will most likely prove to be in vain --- either now or in the very near future.
- atemerev 4y ago
  Well, it is now 2023. Perhaps some things finally improved since the 90s. Or so I would hope (apparently not). If you run HPC jobs, you are stuck with the Linux version your cluster supports (probably not too recent), and you probably won’t be able to build directly there. This is when you need all these hacks.
- skywal_l 4y ago
  > Linux is not oriented toward supporting binary compatibility beyond the most rudimentary level Why do you say this? I am truly curious. My understanding is that the Linux ABI is very stable ("we never break user space" -- Linux Torvald). If you static link the libc, your binary should work on any Linux. I mean, if we were to judge Linux it should be with regards to other operating system of equivalent complexity and use. My understanding is that Windows or macos do not offer this kind of stability over time.
  - agwa 4y ago
    The kernel ABI is very stable, but applications typically need to interact with parts of the operating system besides the kernel, and those parts are not as fanatical when it comes to providing stable interfaces. For example, applications that need to do hostname and username resolution have to interface with NSS, and that breaks if you statically link glibc. Another example is playing audio - this requires interfacing with some userspace audio system like JACK, PulseAudio, or now Pipewire. If you statically link libSDL, it won't work in 5-10 years with whatever the latest fad in audio playback is. But if you dynamically link libSDL, then you can't statically link glibc because libSDL may be linked with a newer version of glibc, causing a conflict. Thus you end up with a quite a mess.
goodpoint 4y ago
Embedding cryptographic libraries? Hell no. Users need to be able to fix vulnerabilities by updating their OSes. Also not everybody lives in a rich country and has infinite Internet traffic and disk space.
TheChaplain 4y ago
AppImage is one solution too.
- mardifoufs 4y ago
  Appimage isn't truly portable, it still usually depends on specific versions of glibc (and other dependencies that it assumes come with the host OS).
- edflsafoiewq 4y ago
  An AppImage is bascially a zip file that extracts itself and then runs a binary in the extracted dir. It's still up to you to make sure the binary inside the AppImage is actually portable.
  - isr 4y ago
    (you probably know this and were simplifying, but for the benefit of others who may not ...) Its a filesystem, not an archive. So its contents aren't extracted anywhere on your drives. It stays within the appimage. The squashfs fs used is optimised for use as a read-only, fast access fs. Entire distro's have been built and used (for over a decade), where everything is contained in 1 or more overlaying squashfs containers. Its close to the most optimal method of distributing AND ACCESSING read-only stuff. All the appimage does is it mounts its internal squashfs, and the runs its internal AppDir program (appimages are essentially "squashed" appdirs) Appdirs themselves are a sadly underrated agnostic pkg'ing format, which have great flexibility & utility (imho).
bitwize 4y ago
1) Build a Windows binary.
- ghqst 4y ago
  it's so odd how this is a strategy thanks wine
- prmoustache 4y ago
  Or just distribute the source and document how to build it. Why that obsession to distribute the binary yourself?
  - okanat 4y ago
    Not everything has to be open source
    - prmoustache 4y ago
      that is debatable, especially on linux.
hburd 4y ago
You can actually override the SDL version at runtime, even if it is statically linked, though they still suggest to link dynamically: https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...
kvnnews 4y ago
If you're interested in this type of thing take a look at Holy Build box. It has a much more thorough write up on this stuff and an actual solution to boot. For everyone else, just maintain a few docker images targeting the top linux distributions and move on with life.
xuhu 4y ago
> Don’t try to statically link libc or libstdc++, this may cause trouble with other system libs you’ll use (because the system libs dynamically link libc and maybe libstdc++ - probably in versions different from what you linked statically. That causes conflicts.) I guess linking libstdc++ statically is fine if it doesn't show up in ldd ?
mike256 4y ago
I don't even need that much. For me it would be great if companies just specify which distro they use to compile/test their binaries. Why is it so hard to give that info? More often than not I get some really long lists instead: We support distro A in version X,Y and Z, ..., distro B in Version X, X2, X3, ..., ... I try 2 or 3 of those combination and they don't really work. Eventually after 2 or 3 more tries, something works but if I had above information, I'd just start a VM with the known working distro after the first failure.
- edflsafoiewq 4y ago
  You can be sure that any software that starts listing off specific supported distros is going to be a nightmare to run. Usually because they've dynamically linked some outdated and obscure lib from the distro repos.
hyperman1 4y ago
How do e.g. firefox or rust handle this?
- steveklabnik 4y ago
  Rust programs that use the standard library link to glibc by default. You can use musl if you prefer. Virtually all pure-rust dependencies are built from source and statically linked when the build happens.
  - hyperman1 4y ago
    But e.g. does Rust explicitly build with an old version of glibc or something?
    - steveklabnik 4y ago
      It builds with whatever is on your system.
sebazzz 4y ago
> glibc ... To work with all (or at least most) Linux distributions released in the last years, you need to link against reasonably old versions of those libs. Well, except for Alphine which is a frequent source for tiny Docker containers.
phendrenad2 4y ago
This is why I don't support Linux.

114 points by synergy20 4y ago

IMHO this is kind of silly to use very old versions of gcc, libc, etc. Instead use the kernel's namespacing, chroot, etc. features to ship your dependencies. I.e. build a flatpak and forget all these archaic tricks and machinations.

FooBarWidget 4y ago
Not all of your users can, or are willing to accept, container-like packages.
- qbasic_forever 4y ago
  It's 2023, these features have been in the kernel for over a decade.
  - smoldesu 4y ago
    Can Flatpak package system services yet?
    - qbasic_forever 4y ago
      I don't think flatpak was designed or intended for services. What service manager will it depend on? It sounds like you probably want systemd portable services: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/
      - smoldesu 4y ago
        If Flatpak wasn't designed or intended for services, I fail to see how it can be recommended as a relevant tool. I get what you're saying about containerization, but Flatpak is as much of a 'solution' to package management as a cork in a bullet wound.
    - jeroenhd 4y ago
      CoreOS (not specifically Fedora CoreOS) used to do that with Docker. I believe the OS ran your standard systemd services and all through interconnected containers. As far as I can tell, the project has been abandoned, though. I don't think Flatpak is the right tool for the job, it's clearly optimized for UI tools and the occasional command line invocation. Snap may be better for composing a working systems, though that comes with the obvious Snap downsides. Systemd has some great tools to accomplish image/container based operating systems, though I'm not sure how common it's used.
- Xelynega 4y ago
  Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't want the container, they can typically compile the source too.
  - Dalewyn 4y ago
    Windows executables are not containers, both in the technical and laymen sense.
  - jeroenhd 4y ago
    Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.
  - badsectoracula 4y ago
    That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).
badsectoracula 4y ago
Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png
- Vogtinator 4y ago
  > (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.
  - badsectoracula 4y ago
    Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
  - robertlagrant 4y ago
jvanderbot 4y ago
Or, you know, build with three tool chains: arm, windows x64, and Linux gnu x64 and get 90% of your users. Static complied dependencies goes a long way.
- qbasic_forever 4y ago
  No like the post mentions you need to target a libc your users have on their system, which they show is best handled by linking to one that's a decade plus old (as a least common denominator most likely to be available). If that sounds silly... then ship your libc and everything you depend on in a flatpak or similar contained system image.
- AnIdiotOnTheNet 4y ago
  Build for Windows, get 90% of potential users. Many of them on Linux!
PaulDavisThe1st 4y ago
flatpak is basically useless for any context where the application is expected to load and execute arbitrary 3rd party shared libraries (aka "plugins"). This rules out most sophisticated audio applications.
- jancsika 4y ago
  Are audio apps the only type of app to use the plugin pattern? I've never seen any other app category mentioned when plugins (or an equivalent descriptor) come up. Does dl_open crash if it can't find an open ALSA connection or something?
  - PaulDavisThe1st 4y ago
    dlopen("plugin.so"); /* Load that super cool reverb plugin */ .... /* oops, the .so is not part of the flatpak ... fail */ Most other systems that do "plugins" tend to use a domain specific language and load the "plugin" as a normal file, rather than via the dynamic linker.

ThrowawayTestr 4y ago

I've always wondered why Linux binaries are incompatible with each other while you double click on an exe and it'll pretty much always work.

zweifuss 4y ago
Before Windows XP (2002) "DLL Hell" used to be a real problem too. Also a lot of current EXEs need at least Windows 7 SP1 to run.
torstenvl 4y ago
It will never truly be the year of the Linux desktop until this is fixed. Even assuming the developers of the major pieces of proprietary software were willing to put in the work to port, say, Photoshop or Word, packaging the result is made intentionally asinine. It's literally easier to run old Windows binaries on a Linux than to run old Linux binaries on Linux.
- chungy 4y ago
  The problem is fixed: AppImage
  - okanat 4y ago
    Nope. They depend on fuse2 which isn't shipped with Opensuse which ships fuse3.
Denvercoder9 4y ago
Windows applications usually ship their own copy of all the libraries they use, instead of relying on the system copy of those libraries; and Microsoft is better at keeping system APIs backward-compatible (for some definition of system). Both approaches have advantages and disadvantages.
- okanat 4y ago
  MS is almost perfect in this matter. You can still run Win 2k binaries. Most proper Windows applications do ship many libraries but they are often really special purpose or actually part of the application via plugin interfaces. On Windows you don't ship the equivalent of libc, libcurl, libssl, libX.. or SDL. You don't have to deal with any of the pains in the article. Those are all in the OS and they have a stable ABI. Moreover this approach makes your binaries more secure by updating more critical points of failure (i.e. web interfaces, crypto) with the OS rather than you as the developer being forced to do so.

timothine 4y ago

If you want to go even further, use something like this https://chromium.googlesource.com/linux-syscall-support https://chromium.googlesource.com/linux-syscall-support and compile statically. The syscall interface is stable enough that you can create binaries that will run against Linux kernels from decades ago, if needed.

capableweb 4y ago
If you want to go even further than that, you can use APE (αcτµαlly pδrταblε εxεcµταblε) which lets you compile a single binary that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD.
- loupol 4y ago
  Cosmopolitan[0] is indeed worth mentioning here. It's an amazing project. [0] https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan
- badsectoracula 4y ago
  Amusingly when i saw the title i assumed it'd be about APE :-P.
- nashashmi 4y ago
  I miss QT web browser. It was a single binary that uses chrome engine.
bjackman 4y ago
Why not just statically link against a normal libc?
- chungy 4y ago
  That's basically musl, and yes, that is the better idea.
- edflsafoiewq 4y ago
  The article explains > Don’t try to statically link libc or libstdc++, this may cause trouble with other system libs you’ll use (because the system libs dynamically link libc and maybe libstdc++ - probably in versions different from what you linked statically. That causes conflicts.)

urbandw311er 4y ago

What an absolute convoluted nightmare.

no_time 4y ago

How about forgetting glibc alltogether and statically linking musl?

flatiron 4y ago
Can you explain the glibc hate? Been using it for 20+ years and really confused why people dislike it.
- atemerev 4y ago
  Because you won’t be able to run your program on a HPC cluster that runs CentOS 7 with an ancient glibc, if you wrote it in C++17 on your Fedora machine. Or basically anywhere else. It will be much easier with musl.
  - bluedino 4y ago
    This hits close to home. We have a handful of versions of GCC and library paths for this reason. ROCKS never upgraded to CentOS 8, new hardware support is becoming an issue, so moving to a new cluster manager and a newer Rocky/Alma/? has been a long time coming.
- TheChaplain 4y ago
  Probably because of just that, it's old and not cool anymore.
  - deleted 4y ago
    [deleted]
- squarefoot 4y ago
  I can't speak for other use cases, but trying a musl based distro on restricted hardware convinced me how good it is. Memory/storage consumption is reduced by a a lot compared to glibc, and it's damn fast. Now I try to run Alpine wherever I need compactness and simplicity.
- 4y ago

EGreg 4y ago

Redbean server, no? Actually portable executables?

EGreg 4y ago
https://justine.lol/ape.html https://justine.lol/ape.html

jqpabc123 4y ago

Or you could simply recognize the obvious --- Linux is not oriented toward supporting binary compatibility beyond the most rudimentary level. Effort in this regard with any app of substance will most likely prove to be in vain --- either now or in the very near future.

atemerev 4y ago
Well, it is now 2023. Perhaps some things finally improved since the 90s. Or so I would hope (apparently not). If you run HPC jobs, you are stuck with the Linux version your cluster supports (probably not too recent), and you probably won’t be able to build directly there. This is when you need all these hacks.
skywal_l 4y ago
> Linux is not oriented toward supporting binary compatibility beyond the most rudimentary level Why do you say this? I am truly curious. My understanding is that the Linux ABI is very stable ("we never break user space" -- Linux Torvald). If you static link the libc, your binary should work on any Linux. I mean, if we were to judge Linux it should be with regards to other operating system of equivalent complexity and use. My understanding is that Windows or macos do not offer this kind of stability over time.
- agwa 4y ago
  The kernel ABI is very stable, but applications typically need to interact with parts of the operating system besides the kernel, and those parts are not as fanatical when it comes to providing stable interfaces. For example, applications that need to do hostname and username resolution have to interface with NSS, and that breaks if you statically link glibc. Another example is playing audio - this requires interfacing with some userspace audio system like JACK, PulseAudio, or now Pipewire. If you statically link libSDL, it won't work in 5-10 years with whatever the latest fad in audio playback is. But if you dynamically link libSDL, then you can't statically link glibc because libSDL may be linked with a newer version of glibc, causing a conflict. Thus you end up with a quite a mess.

goodpoint 4y ago

Embedding cryptographic libraries? Hell no. Users need to be able to fix vulnerabilities by updating their OSes. Also not everybody lives in a rich country and has infinite Internet traffic and disk space.

TheChaplain 4y ago

AppImage is one solution too.

mardifoufs 4y ago
Appimage isn't truly portable, it still usually depends on specific versions of glibc (and other dependencies that it assumes come with the host OS).
edflsafoiewq 4y ago
An AppImage is bascially a zip file that extracts itself and then runs a binary in the extracted dir. It's still up to you to make sure the binary inside the AppImage is actually portable.
- isr 4y ago
  (you probably know this and were simplifying, but for the benefit of others who may not ...) Its a filesystem, not an archive. So its contents aren't extracted anywhere on your drives. It stays within the appimage. The squashfs fs used is optimised for use as a read-only, fast access fs. Entire distro's have been built and used (for over a decade), where everything is contained in 1 or more overlaying squashfs containers. Its close to the most optimal method of distributing AND ACCESSING read-only stuff. All the appimage does is it mounts its internal squashfs, and the runs its internal AppDir program (appimages are essentially "squashed" appdirs) Appdirs themselves are a sadly underrated agnostic pkg'ing format, which have great flexibility & utility (imho).

bitwize 4y ago

1) Build a Windows binary.

ghqst 4y ago
it's so odd how this is a strategy thanks wine
prmoustache 4y ago
Or just distribute the source and document how to build it. Why that obsession to distribute the binary yourself?
- okanat 4y ago
  Not everything has to be open source
  - prmoustache 4y ago
    that is debatable, especially on linux.

hburd 4y ago

You can actually override the SDL version at runtime, even if it is statically linked, though they still suggest to link dynamically: https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

kvnnews 4y ago

If you're interested in this type of thing take a look at Holy Build box. It has a much more thorough write up on this stuff and an actual solution to boot. For everyone else, just maintain a few docker images targeting the top linux distributions and move on with life.

xuhu 4y ago

> Don’t try to statically link libc or libstdc++, this may cause trouble with other system libs you’ll use (because the system libs dynamically link libc and maybe libstdc++ - probably in versions different from what you linked statically. That causes conflicts.) I guess linking libstdc++ statically is fine if it doesn't show up in ldd ?

mike256 4y ago

I don't even need that much. For me it would be great if companies just specify which distro they use to compile/test their binaries. Why is it so hard to give that info? More often than not I get some really long lists instead: We support distro A in version X,Y and Z, ..., distro B in Version X, X2, X3, ..., ... I try 2 or 3 of those combination and they don't really work. Eventually after 2 or 3 more tries, something works but if I had above information, I'd just start a VM with the known working distro after the first failure.

edflsafoiewq 4y ago
You can be sure that any software that starts listing off specific supported distros is going to be a nightmare to run. Usually because they've dynamically linked some outdated and obscure lib from the distro repos.

hyperman1 4y ago

How do e.g. firefox or rust handle this?

steveklabnik 4y ago
Rust programs that use the standard library link to glibc by default. You can use musl if you prefer. Virtually all pure-rust dependencies are built from source and statically linked when the build happens.
- hyperman1 4y ago
  But e.g. does Rust explicitly build with an old version of glibc or something?
  - steveklabnik 4y ago
    It builds with whatever is on your system.

sebazzz 4y ago

> glibc ... To work with all (or at least most) Linux distributions released in the last years, you need to link against reasonably old versions of those libs. Well, except for Alphine which is a frequent source for tiny Docker containers.

phendrenad2 4y ago

This is why I don't support Linux.