| ▲ | einpoklum 13 hours ago |
| This seems interesting even regardless of go. Is it realistic to create an executable which would work on very different kinds of Linux distros? e.g. 32-bit and 64-bit? Or maybe some general framework/library for building an arbitrary program at least for "any libc"? |
|
| ▲ | quesomaster9000 13 hours ago | parent | next [-] |
| Cosmopolitan goes one further: [binaries] that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS on AMD64 and ARM64 https://justine.lol/cosmopolitan/ |
| |
| ▲ | oguz-ismail2 13 hours ago | parent | next [-] | | >Linux if you configure binfmt_misc >Windows if you disable Windows Defender >OpenBSD only older versions | | |
| ▲ | account42 12 hours ago | parent | next [-] | | Yeah while APE is a technically impressive trick, these issues far outweigh the minor convenience of having a single binary. For most cases, a single Windows exe that targets the oldest version you want to support plus a single Glibc binary that dynamically links against the oldest version you want to support and so on is still the best option. | |
| ▲ | yjftsjthsd-h 7 hours ago | parent | prev [-] | | >> Linux > if you configure binfmt_misc I don't think that's a requirement, it'll just fall back to the shell script bootstrap without it. | | |
| ▲ | oguz-ismail2 6 hours ago | parent [-] | | On some distros, yes. On others it'll fire up Wine for whatever reason | | |
| ▲ | yjftsjthsd-h 5 hours ago | parent [-] | | Okay, yes, if you configure binfmt_misc for WINE and not APE then PE-compatible binaries will get run with WINE and not APE. That feels unfair. | | |
| ▲ | oguz-ismail2 5 hours ago | parent [-] | | >if you configure binfmt_misc for WINE It came preconfigured on Ubuntu 20.04 and 22.04, don't know about newer versions. |
|
|
|
| |
| ▲ | dontdoxxme 12 hours ago | parent | prev [-] | | Clearly a joke if it uses the .lol tld. | | |
|
|
| ▲ | 12 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | 13 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | sambuccid 13 hours ago | parent | prev | next [-] |
| Appimage exists that packs linux applications into a single executable file that you just download and open. It works on most linux distros |
| |
| ▲ | greyw 13 hours ago | parent [-] | | I vaguely remember that Appimage-based programs would fail for me because of fuse and glibc symbol version incompatibilties. Gave up them afterwards. If I need to tweak dependencies might as well deal with the packet manager of my distro. |
|
|
| ▲ | iberator 13 hours ago | parent | prev [-] |
| Yup. Just compile it as static executable. Static binaries are very undervalued imo. |
| |
| ▲ | account42 12 hours ago | parent | next [-] | | As TFA points out at the beginning, it's not so simple if you want to use the GPU. | |
| ▲ | flohofwoe 12 hours ago | parent | prev | next [-] | | The "just" is doing a lot of heavylifting here (as detailed in the article), especially for anything that's not a trivial cmdline tool. | | |
| ▲ | Xraider72 11 hours ago | parent | next [-] | | In my experience it seems to be an issue caused by optimizations in legacy code that relied on dlopen to implement a plugin system, or help with startup, since you could lazy load said plugins on demand and start faster. If you forego the requirement of a runtime plugin system, is there anything realistically preventing greenfield projects from just being fully statically linked, assuming their dependencies dont rely on dlopen ? | | |
| ▲ | flohofwoe 11 hours ago | parent [-] | | It becomes tricky when you need to use system DLLs like X11 or GL/Vulkan (so you need to use the 'hacks' described in the article to work around that) - the problem is that those system DLLs then bring a dynamically linked glibc into the process, so suddenly you have two C stdlibs running side by side and the question is whether this works just fine or causes subtle breakage under the hood (e.g. the reason why MUSL doesn't implement dlopen). E.g. in my experience: command line tools are fine to link statically with MUSL, but as soon as you need a window and 3D rendering it's not worth the hassle. | | |
| ▲ | account42 11 hours ago | parent [-] | | X11 actually has a stable wire protocol so you don't strictly need any dynamic libraries for that - it's just that no one bothers because if you want X11 then you most likely also want GPU access where you do need to load hardware-specific libraries. |
|
| |
| ▲ | qznc 12 hours ago | parent | prev [-] | | Ack. I went down that rabbit hole to "just" build a static Python: https://beza1e1.tuxen.de/python_bazel.html |
| |
| ▲ | 12 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | pjmlp 12 hours ago | parent | prev [-] | | We had a time when static binaries where pretty much the only thing we had available. Here is an idea, lets go back to pure UNIX distros using static binaries with OS IPC for any kind of application dynamism, I bet it will work out great, after all it did for several years. Got to put that RAM to use. | | |
| ▲ | flohofwoe 10 hours ago | parent | next [-] | | The thing with static linking is that it enables aggressive dead code elimination (e.g. DLL are a hard optimization barrier). Even with multiple processes sharing the same DLL I would be surprised if the alternative of those processes only containing the code they actually need would increase RAM usage dramatically, especially since most processes that run in the background on a typical Linux system wouldn't event even need to go through glibc but could talk directly to the syscall interface. DLLs are fine as operating system interface as long as they are stable (e.g. Windows does it right, glibc doesn't). But apart from operating system interfaces and plugins, overusing dynamic linking just doesn't make a lot of sense (like on most Linux systems with their package managers). | | |
| ▲ | pjmlp 10 hours ago | parent [-] | | While at the same time it prevents extending applications, the alternatives being multiple processes using OS IPC, all of them much slower and heavier on resources than an indirect call on a dynamic library. We started there in computing history, and outside Linux where this desire to go to the past prevails, moved on to better ways including on other UNIX systems. |
| |
| ▲ | jacquesm 12 hours ago | parent | prev | next [-] | | I've been static linking my executables for years. The downside, that you might end up with an outdated library, is no match for the upsite: just take the binary and run it. As long as you're the only user of the system and the code is your own you're going to be just fine. | |
| ▲ | account42 11 hours ago | parent | prev [-] | | I don't think dynamic libraries fail at "utilizing" any available RAM. | | |
| ▲ | pjmlp 10 hours ago | parent [-] | | Think of any program that uses dynamic libraries as extension mechanism, and now replace it with standard UNIX processes, each using any form of UNIX IPC to talk with the host process instead. | | |
| ▲ | account42 10 hours ago | parent [-] | | In theory there might be a different RAM usage with the two approaches. In practice there is not. | | |
|
|
|
|
