3 ms·

To clarify for Rust; Rust statically links other Rust code into your program by default. That's the relevant comparison in my post, because Haskell also links d

To clarify for Rust; Rust statically links other Rust code into your program by default. That's the relevant comparison in my post, because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Presumably that's what Blikkentrekker meant. If you want to have a 100% static executable, that's been possible for a while now: https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a...

a1369209993 6y ago
> > no documented way to force [the reference implementation, with the standard libraries (in particular libc) that the default system semantics are dependent on] to generate a static executable. > https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a... Yes, I'm aware of that; the fact that they continued using glibc as their default (aka canonical) OS/syscall interface after discovering that it was so impossible to statically link that people had to retarget code to a whole second libc was one of the final nails in the proverbial coffin for me. > because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Not particularly relevant, since my inquery was mainly about Rust, but on my system I get: $ echo 'main = pure ()' > foo.hs $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, /tmp/tmp.icUr2pqZXx/Main.o ) Linking foo ... $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Admittedly, it's entirely possible that I fixed ghc and/or gcc at some point and forgot (I've fixed other bugs, but I don't recall fixing this one).
- lalaithion 6y ago
  Not relevant to what you asked, but relevant to the point that was made higher up in this thread. I think you've fixed something. I get $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux- x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=f9e391e2e7da2c80dbfc7820ac87294ef447c57a, not stripped

a1369209993 6y ago

> > no documented way to force [the reference implementation, with the standard libraries (in particular libc) that the default system semantics are dependent on] to generate a static executable. > https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a... Yes, I'm aware of that; the fact that they continued using glibc as their default (aka canonical) OS/syscall interface after discovering that it was so impossible to statically link that people had to retarget code to a whole second libc was one of the final nails in the proverbial coffin for me. > because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Not particularly relevant, since my inquery was mainly about Rust, but on my system I get: $ echo 'main = pure ()' > foo.hs $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, /tmp/tmp.icUr2pqZXx/Main.o ) Linking foo ... $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Admittedly, it's entirely possible that I fixed ghc and/or gcc at some point and forgot (I've fixed other bugs, but I don't recall fixing this one).

lalaithion 6y ago
Not relevant to what you asked, but relevant to the point that was made higher up in this thread. I think you've fixed something. I get $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux- x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=f9e391e2e7da2c80dbfc7820ac87294ef447c57a, not stripped