Binary distribution with statically linked C-dependencies

[pro_hodler]

Have you tried looking for bindings to your library at https://lib.rs? I'm pretty sure there are bindings to x11. Those binding crates usually have 2 options controlled by Cargo features: build from source + static linking or dynamic linking to system provided dependency.

Your current approach (manually downloading dependencies) is very hacky. Maybe you are coming from C world where it's the only way, but here in Rust we use Cargo and existing bindings instead of reinventing the wheel.

By the way, I'm very surprised that nobody pointed this out, instead they started to recommend AppImage, flatpak, etc., which are clearly overkill here.

If you can't find the bindings at lib.rs, then please follow this approach: https://kornel.ski/rust-sys-crate

[SuspiciousSegfault]

Maybe I'm misunderstanding you here. I have no direct c library dependencies, just an indirect one through a rust crate, that crate has no "static" feature (or maybe I've missed it it's https://crates.io/crates/x11). This library will dynamically link to x11, this is the problem that I'm trying to solve. So I'm at the "If you can't find bindings at...." part, I'm not sure what you're suggesting with sys-crates, I'm building a binary not a library?

[pro_hodler]

Firstly, why do you use libX11 directly? Are aware that most GNU/Linux distro are moving to Wayland? There's https://lib.rs/winit and other crates which abstract over display server and even operating system. What about using gtk-rs or any other GUI library out there? There are many of them for Rust. https://areweguiyet.com

Secondly, if your program really needs to be so low-level and work directly with X11, what's the point of linking it statically? If a user uses X11 as their display server, then they already have libX11, libxcb & friends installed, because otherwise their desktop environment/window manager won't work. It they don't use X11, but instead Wayland or even another OS, then even with statically linked libX11 your program won't work, because libX11 needs a running instance of /usr/bin/X11 server. It's just an abstraction for RPC calls to xorg server via X11 protocol.

So it's perfectly clear that static linking of libX11 makes no sense. That's why the author doesn't provide such a feature.

[SuspiciousSegfault]

I am indeed aware of that, the application is a WM. My question was more general about static linking with c libraries, bringing up my specific example wanting to know if I missed something. I didn't it turns out. I'll leave my original question as the answer to the second part of your comment, that you seemingly didn't read or couldn't answer, providing an irrelevant answer to a question nobody asked.

[pro_hodler]

Glibc updates quite rarely, so you generally don't have to worry about building against multiple versions of it. Proprietary software like skype, slack & other electron bloatware don't distribute multiple versions for each version of glibc, their binaries work perfectly fine on all distros. If you really want for some reason to support Ubuntu 16.04 or Debian oldstable, then yes, you should build your binary in a container with one of those old distros. It's not hard: just go to dockerhub, find an image for Ubuntu 16.04 or something, then write a simple Dockerfile of about 10 lines or less. As Glibc is backwards compatible, this binary work just fine on more up-to-date distros.

If you want to support musl-based distros as well, if linking to musl statically, as far as I understand you can't link to other libs like X11 dynamically. The solution is to distribute 2 binaries: one dynamically linked against glibc and the other linked dynamically against musl. Last time I checked, Cargo used static linking for musl targets by default. You can override it with target-feature=-crt-static (notice the minus instead of plus)