> Rust -- say goodbye to cross-compiling, but if you stay away from OS provided libraries, you are kind of covered;
What? Rust can cross compile perfectly fine.
> C / C++ -- certainly possible, but you'll need on retainer a UNIX graybeard, or at least an autotools-foo master;
If you write C and don't know how to cross compile your code you shouldn't be writing it.
> Python -- you're already covered, just read the zipapp documentation;
Python actually can't cross build (reliably).
> Java -- possible, but you'll need a startup script to just call java -jar some-tool.jar; (also not a good fit for short-lived tools, mainly due to startup times;)
I didn't mean to come off as elitist, but I have never met anyone I'd trust to write a C program that didn't have big obvious bugs that didn't know how to cross compile/statically link a C executable. If you haven't, that means you haven't spent enough time actually coding to be able to feel safe about what you're writing. Which is fine. But then use a language you know or spend more time learning about your tools before complaining. C is simple, everything around it is difficult.
I've written C on and off for decades and have not once needed to cross compile. Many of the best game developers spend their lives using C without ever setting up cross compilation. It just seems like an absurd yardstick.
Last time I tried to cross compile RISC-V with Rust it just didn't work at all. I even know how linkers work and tried my best with custom linker scripts and arguments, but the toolchain would not build a rv64gc. Perhaps they have fixed the issues now, though.
I would like to add that Zig is extremely cross-compilable. You can even use it to cross compile C/C++ projects.
And Nim is fairly easy to cross compile. Just output C or C++ and cross compile that. I don't know why people are saying that cross compiling C or C++ is so miserable. Yes, it's not always a one-liner, but that depends on the toolchain. For example, there is crosstool-ng. Also Linux distros tend to have cross compilers for many architectures right on the box these days.
Here is how to cross-compile to 64-bit RISC-V on my Ubuntu machine:
> Last time I tried to cross compile RISC-V with Rust it just didn't work at all.
YMMV; my experience was actually the opposite, approximately an year ago. I was actually really surprised of being able to build na executable for RISC-V (that I then copied to a VM, and run) all by adding 4 lines to Cargo's config.toml.
Never done RISC-V, but for ARM, this is trivial, one just have to rustup the right target stdlib, and then pass --target to cargo and done.
Well, at least that's that easy if what you try to compile don't have C dependencies. For C dependencies, there is cross <https://github.com/cross-rs/cross> which I had good experiences with.
> If you write C and don't know how to cross compile your code you shouldn't be writing it.
Cross-compiling in C is always miserable to set up, especially around the area of libraries. And it gets worse if one of the compilers is from a different vendor.
I don't think people realize just how much work tools like crosstool NG do to take away the pain of cross compiling. I remember trying to cross compile stuff in the early 2000s before all that tooling existed and.... oh boy, it was nightmare fuel. A good docker container setup makes it even easier these days.
I think clang (https://clang.llvm.org/docs/CrossCompilation.html) even makes crosstool largely irrelevant these days. Just specify your desired triplet on the command-line and off you go cross-compiling (mostly) effortlessly without having to build an entirely new toolchain. It can even masquerade as the MSVC compiler if you so desire.
I came here to say this but instead I am upvoting this. Pyinstaller is awesome.
Another thing to add, if you use run pyinstaller in docker with an old base image and copy the executable out, you can make a pyinstaller executable that will run on a vast range of machines due to runtime backward compatibility. I have single executable python apps that run fine on redhat, debian, ubuntu and suse.
By cross-compiling one usually understands compiling for the *same OS* but different architecture. What about cross-compiling for a *different OS*?
Can I *easily* compile a non-trivial C/C++ application from say Linux to OSX or OpenBSD, for simplicity say all of them are x86 64bit? (Bonus point if the application in question happens to use LMDB or another non-trivial library that plugs intimately into the OS API.)
About Rust, I've once tried to compile from Linux to OSX a quite trivial application (basically a glorified `md5sum`), and the experience wasn't pleasant, and it involved lots of "internet searching" and basically stumbling around... (I don't remember if I succeeded, but I definitely wouldn't try it again.)
> By cross-compiling one usually understands compiling for the same OS but different architecture.
I don't even consider that to rise to the level of "cross compiling".
Getting started with emscripten to target WASM for C and C++ is rather a chore of dependency wrangling IME. Targeting WASM from Rust, OTOH, is trivial. Targeting windows from linux with Rust is also quite straightforward, as has been experimenting with targeting consoles or Android from Windows.
Targeting a MIPS32 OpenDingux target from Windows was much more of a chore. The toolchain with libs, headers, etc. that I used is just a *.tar.bz2 that expects to be extracted to /opt/gcw0-toolchain of a linux distro specifically, and embedded absolute paths all over the place make changing that difficult. I do resort to WSL on Windows, basically only because of those embedded paths: https://github.com/MaulingMonkey/rust-opendingux-test
Acquiring the appropriate libs and headers to link/compile against for cross compiling is always an adventure, but Rust isn't making things any worse IME.
That rust comment does sound weird. It's one of the easiest to compile across platforms. All you need is the rust toolchain and may be openssl sometimes.
The easiest to cross compile would be golang, it’s as easy as setting 1-2 environment variables. Last I used rust it required tool chain setup, which if you’re not familiar with the process and be quite difficult.
I tried cross-compiling a Rust project from ARM macOS host to ARM Linux target, compiling source files is still fine, but during linking stage it threw lots of lots of errors. And it’s a pure Rust project without any system library dependencies. Seems that the system linker also needs to support the target platform, or cross compiling won’t work.
What's your experience with GraalVM? In mine, the need to painstakingly track every single reflection use by getting the stack traces at runtime (and never be quite sure if you got all of them) pretty much killed it for me
It will track all uses of reflection during a program's execution. You can then use the resultant config as the starting point for the reflect-config.json.
Oh, that's nice. I was using it through Quarkus a while ago, not sure if I missed it or it wasn't available yet. That seems like a good starting point, although I assume it can't assure no runtime errors in production
Edit: it seems to me that GraalVM would benefit from a repository of classes and corresponding reflection configs. Like DefinitelyTyped from the Typescript world
What? Rust can cross compile perfectly fine.
> C / C++ -- certainly possible, but you'll need on retainer a UNIX graybeard, or at least an autotools-foo master;
If you write C and don't know how to cross compile your code you shouldn't be writing it.
> Python -- you're already covered, just read the zipapp documentation;
Python actually can't cross build (reliably).
> Java -- possible, but you'll need a startup script to just call java -jar some-tool.jar; (also not a good fit for short-lived tools, mainly due to startup times;)
Use GraalVM.