5 ms·

It is very easy on Windows to create a statically linked executable that you can just copy to wherever you want.

rwmj 8y ago
And it's very easy on Linux to provide a source tarball and let the distro packagers do all the work for you. Plus, you know, static linking exists on Linux too, it's not something that only Windows can do.
- isostatic 8y ago
  Every night we have a job (run by jenkins I think) download the latest ffmpeg code, add some non-approved patched, and cross compile to static binaries for x64 linux, osx, and windows (we've dropped the 32 bit linux build) It's not hard to make a static binary. On the other hand most of the "software" I write - mainly shell scripts - includes things like apache configuration, requires other applications (like apache, iperf, tcpdump, lldp, etc) I want to deploy these to multiple boxes, I want them versioned, I want them easy to update, I want to know what version is installed. All of this is handled by a 10 line config file in a .deb.
- zamadatix 8y ago
  Distro packagers do nothing for you if: - Your app isn't licensed in the way you like - You don't want to provide the source code to your app - They don't find your app interesting enough - They don't agree with your app's policies Static linking is a much better response for actually getting the program running on Linux systems but this still leaves out the "is there a way I can package it once for Linux" problem. Now if it's a CLI only utility/service type tool it's a different story.
  - isostatic 8y ago
    Fine, build your own package. # dpkg-deb --build ./src/ mydeb.deb Stick your dependencies etc in ./src/DEBIAN/control Or just distribute a tar with your application. I used to have to distribute a cross platform java progam. It was horrendous creating the MSI on windows. The linux and osx versions were trivial
    - MaxBarraclough 8y ago
      Java? Shouldn't that just be JAR + JVM?
      - isostatic 8y ago
        Called native executables too, launch icons/shortcuts etc, jvm version detection Deployed by apt/yum/mdm andslme crappy windows thing. The latter was the problem.
- jwatte 8y ago
  Except, if you need to pay rent and put your kids through college, shipping source tarballs is going to significantly reduce revenue for a small developer. (It's sad, but it does.)
- 21 8y ago
  A few years ago I tried to compile a C++ project into a static binary which would work on both Ubuntu and CentOS. Long story short, it wasn't possible. Because the latest versions of Ubuntu and CentOS at the time used different versions of glibc which were mutually incompatible.
  - tathougies 8y ago
    If you statically link, it doesn't matter what version of glibc is on the target machine, because it's not used.
    - 21 8y ago
      You would think so, but it's not true. I struggled with this for a few days before giving up (after finding articles which stated that this is really going where nobody went before) > Static linking of glibc is not supported on Red Hat Enterprise Linux. https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/ https://developers.redhat.com/blog/2016/02/17/upgrading-the-...
      - isostatic 8y ago
        I don't pretend to know a lot about linking files, but I just checked an old static ffmbc binary I had lying around :/tmp$ file ffmbc ffmbc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=...., stripped :/tmp$ ldd ffmbc not a dynamic executable It runs on the following libc versions: ldd (GNU libc) 2.12 (Centos 6.9) ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 (ubuntu 14.04) ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 (Ubuntu 16.04) I'm fairly sure it ran on distributions as old as ubuntu 8.04
  - Spivak 8y ago
    You're supposed to bundle a fixed version of glibc with your application.

rwmj 8y ago

And it's very easy on Linux to provide a source tarball and let the distro packagers do all the work for you. Plus, you know, static linking exists on Linux too, it's not something that only Windows can do.

isostatic 8y ago
Every night we have a job (run by jenkins I think) download the latest ffmpeg code, add some non-approved patched, and cross compile to static binaries for x64 linux, osx, and windows (we've dropped the 32 bit linux build) It's not hard to make a static binary. On the other hand most of the "software" I write - mainly shell scripts - includes things like apache configuration, requires other applications (like apache, iperf, tcpdump, lldp, etc) I want to deploy these to multiple boxes, I want them versioned, I want them easy to update, I want to know what version is installed. All of this is handled by a 10 line config file in a .deb.
zamadatix 8y ago
Distro packagers do nothing for you if: - Your app isn't licensed in the way you like - You don't want to provide the source code to your app - They don't find your app interesting enough - They don't agree with your app's policies Static linking is a much better response for actually getting the program running on Linux systems but this still leaves out the "is there a way I can package it once for Linux" problem. Now if it's a CLI only utility/service type tool it's a different story.
- isostatic 8y ago
  Fine, build your own package. # dpkg-deb --build ./src/ mydeb.deb Stick your dependencies etc in ./src/DEBIAN/control Or just distribute a tar with your application. I used to have to distribute a cross platform java progam. It was horrendous creating the MSI on windows. The linux and osx versions were trivial
  - MaxBarraclough 8y ago
    Java? Shouldn't that just be JAR + JVM?
    - isostatic 8y ago
      Called native executables too, launch icons/shortcuts etc, jvm version detection Deployed by apt/yum/mdm andslme crappy windows thing. The latter was the problem.
jwatte 8y ago
Except, if you need to pay rent and put your kids through college, shipping source tarballs is going to significantly reduce revenue for a small developer. (It's sad, but it does.)
21 8y ago
A few years ago I tried to compile a C++ project into a static binary which would work on both Ubuntu and CentOS. Long story short, it wasn't possible. Because the latest versions of Ubuntu and CentOS at the time used different versions of glibc which were mutually incompatible.
- tathougies 8y ago
  If you statically link, it doesn't matter what version of glibc is on the target machine, because it's not used.
  - 21 8y ago
    You would think so, but it's not true. I struggled with this for a few days before giving up (after finding articles which stated that this is really going where nobody went before) > Static linking of glibc is not supported on Red Hat Enterprise Linux. https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/ https://developers.redhat.com/blog/2016/02/17/upgrading-the-...
    - isostatic 8y ago
      I don't pretend to know a lot about linking files, but I just checked an old static ffmbc binary I had lying around :/tmp$ file ffmbc ffmbc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=...., stripped :/tmp$ ldd ffmbc not a dynamic executable It runs on the following libc versions: ldd (GNU libc) 2.12 (Centos 6.9) ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 (ubuntu 14.04) ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 (Ubuntu 16.04) I'm fairly sure it ran on distributions as old as ubuntu 8.04
- Spivak 8y ago
  You're supposed to bundle a fixed version of glibc with your application.