Static binary

[probonopd]

Hello @ryanabx. Very interesting project! In fact, I have wondered for a long time whether writing an AppImage runtime in Rust would be a) feasible and b) beneficial. Unfortunately, I have never done anything with Rust so far.

Could you please add some instructions how to create a static binary for the runtime? It should not depend on glibc (or another C library) being present on the target system. For https://github.com/AppImage/type2-runtime, we are statically linking musl libc.

This is what I figured out so far:

• Rust already links most libraries (but not the C standard library) statically
• It may be possible to link musl libc statically, creating a fully static binary, by using something along these lines:

# Install Rust if not already installed (as a user, not as root)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. ~/.cargo/env

sudo apt-get -y install libfuse3 

cargo build --release

# This works, but dynamically links glibc
# Hence we try:

mkdir -p .cargo
cat > .cargo/config.toml <<\EOF
[build]
target = "x86_64-unknown-linux-musl"

[target.'cfg(target_os = "linux")']
rustflags = ["-C", "linker=ld.lld", "-C", "relocation-model=static", "-C", "strip=symbols"]
EOF

rustup target add x86_64-unknown-linux-musl

cargo build --release

This gives

--- stderr
  pkg-config has not been configured to support cross-compilation.

  Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.
  pkg-config has not been configured to support cross-compilation.

How to proceed?

For https://github.com/AppImage/type2-runtime, we are building the whole thing in an Alpine Linux chroot. Do we need something similar here?

(At this point I am mainly interested in finding out how large an entirely static AppImage runtime written in Rust might be.)

[ryanabx]

Hi, I'm glad you're interested in this project! :)

I agree that having everything statically linked would be the ideal here, and I appreciate you looking into the initial details for it. Since I'm not an expert on glibc, musl, and whatnot, I don't know what the caveats are for using musl statically instead of dynamically linking to glibc, but it's definitely something I'd like to explore.

My first goal with this runtime is to make a working appimage with it. The last thing I was working on with the project was https://github.com/linux-packaging-rs/squashfuse-rs because there wasn't a squashfs fuse implementation written in rust. I'm still working out the kinks on that implementation, because I'm not a squashfs expert nor a fuse expert 😆

A lot of the squashfuse stuff rn is just me mounting a squashfs image and trying to traverse it and see what's working and what's not. If you know anyone with squashfs knowledge and is willing to program in rust that'd definitely be a space where I could use some help!

After I get a working appimage with this, maybe then the "everything statically linked" topic will be more on my mind.

[probonopd]

Thanks for the update @ryanabx. No hurries. Adding Rust to my learning TODO list. Unfortunately I don't know anyone with that skillset. You decided against calling into C libsquashfuse by choice, or is that not possible from Rust?

[ryanabx]

Thanks for the update @ryanabx. No hurries. Adding Rust to my learning TODO list. Unfortunately I don't know anyone with that skillset. You decided against calling into C libsquashfuse by choice, or is that not possible from Rust?

It's possible, when people want to use a C library they will just use FFI
https://doc.rust-lang.org/rust-by-example/std_misc/ffi.html
https://doc.rust-lang.org/nomicon/ffi.html

I wanted to take a stab at getting the entire stack (or as much of it as possible) in rust. We could always just call into libsquashfuse if it ends up being too cumbersome to recreate a squashfs fuse implementation in rust.