3 ms·

If this can produce static executables on Linux we may have a winner. We are in the process of selecting a language for $product and we need to pick one everyon

If this can produce static executables on Linux we may have a winner. We are in the process of selecting a language for $product and we need to pick one everyone is happy with, that boils down to static ELFs. My pick would have been Nim or perhaps ChowJS if it works like they say it does, but it would be even nicer if C# was a possibility. Basically "ldd $file" needs to say "not a dynamic executable". Also, no dlopen().

jeroenhd 4y ago
Currently, dotnet is able to build binaries for Linux that only depend on the following libraries (hello world app, according to readelf -d): - libcstdc++.so.6 - libm.so.6 - libgcc_s.so.1 - libc.so.6 You can also exchange some dependencies by compiling with profile linux-musl-x64 instead of linuxe-x64 (no libc, no libm, but with libc.musl-x86_64.so.1) to shrink everything down to the bare minimum. While this isn't a completely statically linked executable, I think it's all you need for most distributions. The important part is that you don't need to install any runtimes on the remote machine to run the executable. I'd love for dotnet to also get static compilation options to get rid of the last few dependencies but when your goal is to just distribute the binary so others can run it, I think dotnet is already there.
- pjc50 4y ago
  It's remarkably hard to ditch dynamic loading completely when using GNU libc, even when writing directly in C. A surprising range of POSIX functions require it - anything touching usernames, for example, requires it in case it's running on a complex PAM setup.
SemanticStrengh 4y ago
Why not Java/Kotlin AOT via GraalVM ?
- lmm 4y ago
  Because it's a massive complex pile of underdocumented flakiness? Although I imagine this will be to start with too.
  - SemanticStrengh 4y ago
    please provide substance, this mere dismissal seems ungrounded, GraalVM native in most cases just works(tm). There is some config if you make heavy use of reflection and that is pretty much all.
    - vips7L 4y ago
      It in most cases just does not work. I have never been able to compile a non-trivial project with graal unless I’m using some framework like Quarkus. As soon as there’s any of type of dependencies involved you are going to hit hidden complexities around reflection and class loading.
      - SemanticStrengh 4y ago
        thanks for the input, any example you'd recommend me to try?
- singularity2001 4y ago
  The last time I checked it took 3 seconds to compile Hello_World.kt
  - SemanticStrengh 4y ago
    Kotlin native or graalvm AOT? The new kotlin K2 frontend should help a lot but it won't be stable until 1 year. Also JIT for development and AOT for releases seems very viable to me
rcarmo 4y ago
Well, I'm looking forward to updating my tests of .NET 6 (with the previous AOT functionality, things were already pretty promising, even for GUI apps): https://taoofmac.com/space/blog/2021/11/14/1600 https://taoofmac.com/space/blog/2021/11/14/1600
donatj 4y ago
Why not Go? Stand-alone binaries everywhere all the time.
- eatonphil 4y ago
  Except for when you use cgo (well at least it just gets harder then).
jcelerier 4y ago
> Basically "ldd $file" needs to say "not a dynamic executable". Also, no dlopen(). so, uh, what's wrong with g++ -static foo.cpp ? Note that however you cannot make something that will make any use of OpenGL if you do this as you would have to link statically against the GL implementation, thus forcing a specific driver and requiring a specific graphics card. It's also not possible at all on windows and macOS (unless you restrict to a specific point release there).
- my123 4y ago
  > so, uh, what's wrong with g++ -static foo.cpp glibc is LGPL, so license incompatibility might ensue if you aren't using musl. And it's far more than just OpenGL as an issue, there's PAM too among other things. Windows and macOS don't have stable syscall ABIs in the first place.
  - jcelerier 4y ago
    LGPL can be statically linked with non-gpl-compatible code. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
    - my123 4y ago
      For proprietary code, shipping object files often gives out details that the vendor explicitly doesn't want to be released. So unless the vendor has a specific toolchain for stripping info from those (like NVIDIA for their kernel modules...) not a good option :/

jeroenhd 4y ago

Currently, dotnet is able to build binaries for Linux that only depend on the following libraries (hello world app, according to readelf -d): - libcstdc++.so.6 - libm.so.6 - libgcc_s.so.1 - libc.so.6 You can also exchange some dependencies by compiling with profile linux-musl-x64 instead of linuxe-x64 (no libc, no libm, but with libc.musl-x86_64.so.1) to shrink everything down to the bare minimum. While this isn't a completely statically linked executable, I think it's all you need for most distributions. The important part is that you don't need to install any runtimes on the remote machine to run the executable. I'd love for dotnet to also get static compilation options to get rid of the last few dependencies but when your goal is to just distribute the binary so others can run it, I think dotnet is already there.

pjc50 4y ago
It's remarkably hard to ditch dynamic loading completely when using GNU libc, even when writing directly in C. A surprising range of POSIX functions require it - anything touching usernames, for example, requires it in case it's running on a complex PAM setup.

SemanticStrengh 4y ago

Why not Java/Kotlin AOT via GraalVM ?

lmm 4y ago
Because it's a massive complex pile of underdocumented flakiness? Although I imagine this will be to start with too.
- SemanticStrengh 4y ago
  please provide substance, this mere dismissal seems ungrounded, GraalVM native in most cases just works(tm). There is some config if you make heavy use of reflection and that is pretty much all.
  - vips7L 4y ago
    It in most cases just does not work. I have never been able to compile a non-trivial project with graal unless I’m using some framework like Quarkus. As soon as there’s any of type of dependencies involved you are going to hit hidden complexities around reflection and class loading.
    - SemanticStrengh 4y ago
      thanks for the input, any example you'd recommend me to try?
singularity2001 4y ago
The last time I checked it took 3 seconds to compile Hello_World.kt
- SemanticStrengh 4y ago
  Kotlin native or graalvm AOT? The new kotlin K2 frontend should help a lot but it won't be stable until 1 year. Also JIT for development and AOT for releases seems very viable to me

rcarmo 4y ago

Well, I'm looking forward to updating my tests of .NET 6 (with the previous AOT functionality, things were already pretty promising, even for GUI apps): https://taoofmac.com/space/blog/2021/11/14/1600 https://taoofmac.com/space/blog/2021/11/14/1600

donatj 4y ago

Why not Go? Stand-alone binaries everywhere all the time.

eatonphil 4y ago
Except for when you use cgo (well at least it just gets harder then).

jcelerier 4y ago

> Basically "ldd $file" needs to say "not a dynamic executable". Also, no dlopen(). so, uh, what's wrong with g++ -static foo.cpp ? Note that however you cannot make something that will make any use of OpenGL if you do this as you would have to link statically against the GL implementation, thus forcing a specific driver and requiring a specific graphics card. It's also not possible at all on windows and macOS (unless you restrict to a specific point release there).

my123 4y ago
> so, uh, what's wrong with g++ -static foo.cpp glibc is LGPL, so license incompatibility might ensue if you aren't using musl. And it's far more than just OpenGL as an issue, there's PAM too among other things. Windows and macOS don't have stable syscall ABIs in the first place.
- jcelerier 4y ago
  LGPL can be statically linked with non-gpl-compatible code. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
  - my123 4y ago
    For proprietary code, shipping object files often gives out details that the vendor explicitly doesn't want to be released. So unless the vendor has a specific toolchain for stripping info from those (like NVIDIA for their kernel modules...) not a good option :/