new | ask | show | jobs
optionalsquid 4 days ago  [ - ]

There's a lot more involved in distributing C (and C++) programs than just compiling them:

I'm assuming a Linux based system here, but consider the case where you have external dependencies. If you don't want to require that the user installs those, then you gotta bundle then or link them statically, which is its own can of worms.

Not to mention that a user with an older glibc may not be able to run your executable, even if they have your dependencies installed. Which you can, for example, solve by building against musl or a similar glibc alternative. But in the case of musl, the cost is a significant overhead if your program does a lot of allocations, due to it lacking many of the optimizations found in glibc's malloc. Mitigating that is yet another can of worms.

There's a reason why tools like Snap, AppImage, Docker, and many more exist, each of which are their own can of worms

the__alchemist 4 days ago  [ - ]

Yea def. I think Linux's ABI diaspora and the way it handles dependencies is pain, and the root behind both those distro methods you mention, and why software is distributed as source instead of binaries. I contrast this with Rust. (And I know you can do this with C and C++, but it's not the norm:

  - Distribute a single binary (Or zip with with a Readme, license etc) for Windows
  - Distribute a single binary (or zip etc) for each broad Linux distro; you can cover the majority with 2 or 3. Make sure to compile on an older system (Or WSL edition), as you generally get forward compatibility, but not backwards.
  - If someone's running a Linux distro other than what you built, they can `cargo build --release`, and it will *just work*.
optionalsquid 3 days ago  [ - ]

Another nice thing is that, if you can live with the slower musl malloc, then building a "universal" Linux binary with Cargo takes just two commands:

$ rustup target add x86_64-unknown-linux-musl

$ cargo build --target x86_64-unknown-linux-musl --release

Similarly for cross-compiling for Windows

tyingq 3 days ago  [ - ]

It may be fixed now, but devil's in the details. As one example, musl has (or had) chronic issues with it's dns resolver and large responses.

optionalsquid 3 days ago  [ - ]

Definitely. I haven't tried building anything that requires DNS using musl, but I've had to work around musl's much, much slower malloc implementation

The musl wiki lists a number of differences between it and glibc that can have an impact:

https://wiki.musl-libc.org/functional-differences-from-glibc...

the__alchemist 3 days ago  [ - ]

I should try that!