6 ms·

> Languages suitable for single binary executables > C/C++: certainly possible, but you'll need on retainer a UNIX graybeard, or at least an autotools-foo mast

> Languages suitable for single binary executables > C/C++: certainly possible, but you'll need on retainer a UNIX graybeard, or at least an autotools-foo master I don't understand this. The "C/C++ is black magic!!" meme just never seems to go away. They both support static linking and always have. It mostly comes down whether you dependencies will work with it, and setting appropriate compiler flags. In other words, not terribly different than anything other supporting language.

TillE 5y ago
Yeah you just...link to static libraries. Which have usually already been built and installed alongside the shared libraries. Also why would you be using autotools in 2022? CMake has been the de facto standard for about a decade now.
- bally0241 5y ago
  Came here to say this, anyone still using autohell in 2022 either is a stubborn grey beard or is seriously masochistic. Building static or shared libs/programs with CMake is treated simply as an option when calling the linker. I personally don't know anyone sane who wants to deal with the mental gymnastics needed by libtool. And don't get me started on the stupid permissions games played by 'make distcheck' where a simple git --archive would do just fine.
  - lenkite 5y ago
    Using CMake is like trying to do one-handed pushups to setup your build. Use https://mesonbuild.com/ https://mesonbuild.com/ and make your life comfortable as a couch potato.
_3u10 5y ago
It’s probably more realistic to have a single folder executable like .app “files” on OSX. If the app has assets it gets a little crazy quite quickly.
- zozbot234 5y ago
  AppImage does pretty much that out of the box.
  - rathboma 5y ago
    AppImages are so good. They 'just work'. They're super easy to build and distribute too. I think more Linux distributions should embrace them as the de-facto app standard to replace snap and flatpak.
- teakettle42 5y ago
  BeOS/Haiku appends assets to the end of the ELF file with a ToC and some easy-to-use APIs for accessing them. I always wish that’d taken off. I guess AppImage isn’t dissimilar in that it appends a squashfs image to be mounted with FUSE.
  - immibis 5y ago
    Windows also does this. Linux doesn't, preferring to KISS because with demand paging there's really no reason you can't just put them in your rodata section.
- AnIdiotOnTheNet 5y ago
  There actually is/was two standards for this in Linux: GNUStep Application Bundles[0] and ROX-Filer AppDirs. Currently AppImage is trying to keep the dream alive, but it bundles the files in a squashfs image attached to the executable. [0] Which of course came from NeXT Application Bundles, which is also where OSX Application Bundles came from.
Kenji 5y ago
deleted 5y ago
[deleted]
doliveira 5y ago
> The "C/C++ is black magic!!" meme just never seems to go away It's true, though. Proof of that is how many tools are made basically because no one wants to deal with Makefiles and autotools. I'd argue that even Docker fits this category of tools made to hide C/C++ builds away
- jcelerier 5y ago
  > It's true, though. Proof of that is how many tools are made basically because no one wants to deal with Makefiles and autotools. no one wants to deal with Makefiles and autotools because as of 2022 they don't support spaces in paths and the most used desktop OS on the planet happens to have spaces in the default path for installing software
  - trinovantes 5y ago
    IIRC Microsoft specifically added the space in the default path so that developers know they need to handle file paths with spaces
BeeOnRope 5y ago
Creating a portable single-executable in C/C++ on Linux is not particularly easy. The dominant libc for Linux, glibc, says "static linking is highly discouraged", see [1] among many other sources for the subtle problems it causes. There are solutions like [2], [3], and [4] but they all have downsides and don't compare at all to e.g., the go (or even rust) single-executable story. --- [1] https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical... [2] Link glibc anyway and try to avoid the pitfalls. [3] Link glibc dynamically but everything else static, and build your exe using an ancient toolchain (or better, a new toolchain built for an ancient libc) so that it works on most distros. [4] Give up on glibc and statically link an alternative libc like musl.
- kristov 5y ago
  Or just dynamic link to libc and static link the rest as much as you can. If a binary dynamically links to libc, but is otherwise statically linked, all good no?
  - admax88qqq 5y ago
    Pretty good. Glibc does update occasionally. I've hit issues in the past trying to run old proprietary binaries that required libc.so.5 But yeah that's pretty rare tbh.
    - BeeOnRope 5y ago
      The major library version number (e.g., 5 vs 6) isn't enough: the symbols even within lib.so.6 are versions and some may update every glibc version, so in general you may have problems building against a new libc 6 then running on a system with an old libc 6 (you'll get a runtime error from the dynamic loader complaining a missing versioned symbol).
      - admax88qqq 5y ago
        Yay for "semantic versioning" lol.
mwcampbell 5y ago
One big problem is the global symbol namespace when statically linking. If I'm not mistaken, Rust and Go are able to work around this by mangling their symbols. But it's way too easy for a C or C++ library to pollute the global namespace. Granted, on Linux, the symbol namespace is also global when dynamically linking, but that's not the case on Windows; I'm not sure about Darwin. Combine that with the multiplicity of build systems, and it's easier to just use dynamic linking. Go and Rust solve that by having a standard build system.
- dboreham 5y ago
  Hmm. I wrote C and C++ for 20 years and while I haven't used either in some time, I don't remember this ever being a problem, except when trying to port Unix code that expected errno to be global to Windows (but that's the opposite problem of the one you're talking about).
- rkeene2 5y ago
  Darwin also uses heirarchical namespaces by default; On Linux you can do this to a limited extent with dlmopen() but not as much as you may want (e.g., to link in a library linked to another libc -- but this is unique to Linux, most platforms only have the single libc)

TillE 5y ago

Yeah you just...link to static libraries. Which have usually already been built and installed alongside the shared libraries. Also why would you be using autotools in 2022? CMake has been the de facto standard for about a decade now.

bally0241 5y ago
Came here to say this, anyone still using autohell in 2022 either is a stubborn grey beard or is seriously masochistic. Building static or shared libs/programs with CMake is treated simply as an option when calling the linker. I personally don't know anyone sane who wants to deal with the mental gymnastics needed by libtool. And don't get me started on the stupid permissions games played by 'make distcheck' where a simple git --archive would do just fine.
- lenkite 5y ago
  Using CMake is like trying to do one-handed pushups to setup your build. Use https://mesonbuild.com/ https://mesonbuild.com/ and make your life comfortable as a couch potato.

_3u10 5y ago

It’s probably more realistic to have a single folder executable like .app “files” on OSX. If the app has assets it gets a little crazy quite quickly.

zozbot234 5y ago
AppImage does pretty much that out of the box.
- rathboma 5y ago
  AppImages are so good. They 'just work'. They're super easy to build and distribute too. I think more Linux distributions should embrace them as the de-facto app standard to replace snap and flatpak.
teakettle42 5y ago
BeOS/Haiku appends assets to the end of the ELF file with a ToC and some easy-to-use APIs for accessing them. I always wish that’d taken off. I guess AppImage isn’t dissimilar in that it appends a squashfs image to be mounted with FUSE.
- immibis 5y ago
  Windows also does this. Linux doesn't, preferring to KISS because with demand paging there's really no reason you can't just put them in your rodata section.
AnIdiotOnTheNet 5y ago
There actually is/was two standards for this in Linux: GNUStep Application Bundles[0] and ROX-Filer AppDirs. Currently AppImage is trying to keep the dream alive, but it bundles the files in a squashfs image attached to the executable. [0] Which of course came from NeXT Application Bundles, which is also where OSX Application Bundles came from.

Kenji 5y ago

deleted 5y ago

[deleted]

doliveira 5y ago

> The "C/C++ is black magic!!" meme just never seems to go away It's true, though. Proof of that is how many tools are made basically because no one wants to deal with Makefiles and autotools. I'd argue that even Docker fits this category of tools made to hide C/C++ builds away

jcelerier 5y ago
> It's true, though. Proof of that is how many tools are made basically because no one wants to deal with Makefiles and autotools. no one wants to deal with Makefiles and autotools because as of 2022 they don't support spaces in paths and the most used desktop OS on the planet happens to have spaces in the default path for installing software
- trinovantes 5y ago
  IIRC Microsoft specifically added the space in the default path so that developers know they need to handle file paths with spaces

BeeOnRope 5y ago

Creating a portable single-executable in C/C++ on Linux is not particularly easy. The dominant libc for Linux, glibc, says "static linking is highly discouraged", see [1] among many other sources for the subtle problems it causes. There are solutions like [2], [3], and [4] but they all have downsides and don't compare at all to e.g., the go (or even rust) single-executable story. --- [1] https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical... [2] Link glibc anyway and try to avoid the pitfalls. [3] Link glibc dynamically but everything else static, and build your exe using an ancient toolchain (or better, a new toolchain built for an ancient libc) so that it works on most distros. [4] Give up on glibc and statically link an alternative libc like musl.

kristov 5y ago
Or just dynamic link to libc and static link the rest as much as you can. If a binary dynamically links to libc, but is otherwise statically linked, all good no?
- admax88qqq 5y ago
  Pretty good. Glibc does update occasionally. I've hit issues in the past trying to run old proprietary binaries that required libc.so.5 But yeah that's pretty rare tbh.
  - BeeOnRope 5y ago
    The major library version number (e.g., 5 vs 6) isn't enough: the symbols even within lib.so.6 are versions and some may update every glibc version, so in general you may have problems building against a new libc 6 then running on a system with an old libc 6 (you'll get a runtime error from the dynamic loader complaining a missing versioned symbol).
    - admax88qqq 5y ago
      Yay for "semantic versioning" lol.

mwcampbell 5y ago

One big problem is the global symbol namespace when statically linking. If I'm not mistaken, Rust and Go are able to work around this by mangling their symbols. But it's way too easy for a C or C++ library to pollute the global namespace. Granted, on Linux, the symbol namespace is also global when dynamically linking, but that's not the case on Windows; I'm not sure about Darwin. Combine that with the multiplicity of build systems, and it's easier to just use dynamic linking. Go and Rust solve that by having a standard build system.

dboreham 5y ago
Hmm. I wrote C and C++ for 20 years and while I haven't used either in some time, I don't remember this ever being a problem, except when trying to port Unix code that expected errno to be global to Windows (but that's the opposite problem of the one you're talking about).
rkeene2 5y ago
Darwin also uses heirarchical namespaces by default; On Linux you can do this to a limited extent with dlmopen() but not as much as you may want (e.g., to link in a library linked to another libc -- but this is unique to Linux, most platforms only have the single libc)