Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
ripgrep
ripgrep recursively searches directories for a regex pattern while respecting your gitignore
-
-
Rust has supported producing statically linked binaries since RFC #1721 which proposed the target-feature=+crt-static flag to statically link the platform C library into the final binary. This was initially only supported for Windows MSVC and the MUSL C library. While MUSL works for most people, it has many problems by virtue of being a work-in-progress such as unpredictable performance and many unimplemented features which programs tend to assume are present due to glibc being ubiquitous. In lieu of these concerns, support was added to Rust in 2019 to be able to statically link against glibc.
Rust has supported producing statically linked binaries since RFC #1721 which proposed the target-feature=+crt-static flag to statically link the platform C library into the final binary. This was initially only supported for Windows MSVC and the MUSL C library. While MUSL works for most people, it has many problems by virtue of being a work-in-progress such as unpredictable performance and many unimplemented features which programs tend to assume are present due to glibc being ubiquitous. In lieu of these concerns, support was added to Rust in 2019 to be able to statically link against glibc.
You may be unable to statically link your binary even after all this, due to dependencies that mandate dynamic linking. In some cases this is avoidable, such as using rustls in place of OpenSSL for cryptography, and hyper in place of bindings to cURL for HTTP, not so much in others. Thanks to the convention of native-linking crates using the -sys suffix in their name it is fairly simple to find if your build has dependencies that dynamically link to libraries. Using cargo's native tree subcommand and greping (or ripgreping for me), you can locate native dependencies. Running cargo tree | rg -- -sys against androidx-release-watcher's v4.1.0 release gives us this:
You may be unable to statically link your binary even after all this, due to dependencies that mandate dynamic linking. In some cases this is avoidable, such as using rustls in place of OpenSSL for cryptography, and hyper in place of bindings to cURL for HTTP, not so much in others. Thanks to the convention of native-linking crates using the -sys suffix in their name it is fairly simple to find if your build has dependencies that dynamically link to libraries. Using cargo's native tree subcommand and greping (or ripgreping for me), you can locate native dependencies. Running cargo tree | rg -- -sys against androidx-release-watcher's v4.1.0 release gives us this:
This indicates curl, zlib, openssl, and libnghttp2 as well as a bunch of WASM-related things are being dynamically linked into my executable. To resolve this, I looked at the build features exposed by surf and found that it selects the "curl_client" feature by default, which can be turned off and replaced with "h1-client-rustls" which uses an HTTP client backed by rustls and async-std and no dynamically linked libraries. Enabling this build feature removed all -sys dependencies from androidx-release-watcher, allowing me to build static executables of it.
This indicates curl, zlib, openssl, and libnghttp2 as well as a bunch of WASM-related things are being dynamically linked into my executable. To resolve this, I looked at the build features exposed by surf and found that it selects the "curl_client" feature by default, which can be turned off and replaced with "h1-client-rustls" which uses an HTTP client backed by rustls and async-std and no dynamically linked libraries. Enabling this build feature removed all -sys dependencies from androidx-release-watcher, allowing me to build static executables of it.