3 ms·

I guess this means it can compete with golang on ease of distribution. Pushes all the complexity away from the end user

e63f67dd-065b 2y ago
Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.
- School-Cotton 2y ago
  Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.
  - Cyph0n 2y ago
    Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
    - MrDrMcCoy 2y ago
      I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.
      - kibwen 2y ago
        What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.
        burntsushi 2y ago
        I just tried this myself and I did not have a painless experience. Hah. Without the `musl` Archlinux package installed, I get this: --- stderr configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build': configure: error: C compiler cannot create executables See `config.log' for more details thread 'main' panicked at /home/andrew/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jemalloc-sys-0.5.4+5.3.0-patched/build.rs:351:9: command did not execute successfully: cd "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build" && CC="musl-gcc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" CPPFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" LDFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" "sh" "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build/configure" "--disable-cxx" "--enable-doc=no" "--enable-shared=no" "--with-jemalloc-prefix=_rjem_" "--with-private-namespace=_rjem_" "--host=x86_64-unknown-linux-musl" "--build=x86_64-unknown-linux-gnu" "--prefix=/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out" expected success, got: exit status: 77 Notice, in particular, that there is `CC=musl-gcc` in the error above. But: $ which musl-gcc musl-gcc not found I think the spoiler here is the fact that ripgrep uses jemalloc when you build with musl on 64-bit: https://github.com/BurntSushi/ripgrep/blob/c9ebcbd8abe48c8336fb4826df7e9b6fb179de03/crates/core/main.rs#L19-L40 https://github.com/BurntSushi/ripgrep/blob/c9ebcbd8abe48c833... If you comment out those lines and remove the `jemallocator` dependency from `Cargo.toml`, then the build succeeds. I imagine you'll run into this same problem if you enable ripgrep's `pcre2` feature. However, after installing the `musl` Archlinux package (which provides `musl-gcc`, among other things of course), then the above command builds just fine. Including with `jemallocator` or even with the `pcre2` feature enabled.
        kibwen 2y ago
        Interesting, I must have had musl preinstalled from some other package. And I did notice that jemallocator started showing up when I compiled for musl, I figured you must have had a good reason. :P
    - freedomben 2y ago
      (not directed at parent specifically) Do you have to link againt musl? I have some C applications that I link into a static binary using the glibc-static package (in Fedora). Can the same be used with Rust?
      - School-Cotton 2y ago
        Nothing stops you from linking against glibc statically from rust. It’s recommended to link against glibc dynamically, but that’s just as true for any language.
  - seabrookmx 2y ago
    Same with golang! You need the CGO_ENABLED=0 flag IIRC to make static binaries on Linux.
- fuzztester 2y ago
  >the trend of statically linked binaries that came with Rust/Go "Trend"? Maybe "recent reverse trend" is more appropriate. Static linking preceded dynamic linking by several years, for compiled languages, AFAIK. https://en.m.wikipedia.org/wiki/Static_library https://en.m.wikipedia.org/wiki/Static_library https://en.m.wikipedia.org/wiki/Dynamic_linker https://en.m.wikipedia.org/wiki/Dynamic_linker

Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.

School-Cotton 2y ago
Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.
- Cyph0n 2y ago
  Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
  - MrDrMcCoy 2y ago
    I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.
    - kibwen 2y ago
      What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.
      - burntsushi 2y ago
        I just tried this myself and I did not have a painless experience. Hah. Without the `musl` Archlinux package installed, I get this: --- stderr configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build': configure: error: C compiler cannot create executables See `config.log' for more details thread 'main' panicked at /home/andrew/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jemalloc-sys-0.5.4+5.3.0-patched/build.rs:351:9: command did not execute successfully: cd "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build" && CC="musl-gcc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" CPPFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" LDFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" "sh" "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build/configure" "--disable-cxx" "--enable-doc=no" "--enable-shared=no" "--with-jemalloc-prefix=_rjem_" "--with-private-namespace=_rjem_" "--host=x86_64-unknown-linux-musl" "--build=x86_64-unknown-linux-gnu" "--prefix=/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out" expected success, got: exit status: 77 Notice, in particular, that there is `CC=musl-gcc` in the error above. But: $ which musl-gcc musl-gcc not found I think the spoiler here is the fact that ripgrep uses jemalloc when you build with musl on 64-bit: https://github.com/BurntSushi/ripgrep/blob/c9ebcbd8abe48c8336fb4826df7e9b6fb179de03/crates/core/main.rs#L19-L40 https://github.com/BurntSushi/ripgrep/blob/c9ebcbd8abe48c833... If you comment out those lines and remove the `jemallocator` dependency from `Cargo.toml`, then the build succeeds. I imagine you'll run into this same problem if you enable ripgrep's `pcre2` feature. However, after installing the `musl` Archlinux package (which provides `musl-gcc`, among other things of course), then the above command builds just fine. Including with `jemallocator` or even with the `pcre2` feature enabled.
        kibwen 2y ago
        Interesting, I must have had musl preinstalled from some other package. And I did notice that jemallocator started showing up when I compiled for musl, I figured you must have had a good reason. :P
  - freedomben 2y ago
    (not directed at parent specifically) Do you have to link againt musl? I have some C applications that I link into a static binary using the glibc-static package (in Fedora). Can the same be used with Rust?
    - School-Cotton 2y ago
      Nothing stops you from linking against glibc statically from rust. It’s recommended to link against glibc dynamically, but that’s just as true for any language.
- seabrookmx 2y ago
  Same with golang! You need the CGO_ENABLED=0 flag IIRC to make static binaries on Linux.
fuzztester 2y ago
>the trend of statically linked binaries that came with Rust/Go "Trend"? Maybe "recent reverse trend" is more appropriate. Static linking preceded dynamic linking by several years, for compiled languages, AFAIK. https://en.m.wikipedia.org/wiki/Static_library https://en.m.wikipedia.org/wiki/Static_library https://en.m.wikipedia.org/wiki/Dynamic_linker https://en.m.wikipedia.org/wiki/Dynamic_linker