There are some cases in which that is indeed a deal-breaker or, at least, wouldn’t be practical. Take for instance a binary which needs to be injected into the address space of other processes, having external dependencies would require to map those first and it would pollute the address space. It certainly wouldn’t be pretty. 🙂

Well, there are some software solutions for which it is necessary to deploy a monolithic executable. These could be, for instance, utilities for forensic purposes, like evidence gathering. Having dependencies would be terrible if the solution needs to be made simple to deploy. Of course, with Qt DLLs it would be possible to write a self-extracting executable, but that wouldn’t be efficient neither in size nor performance.

I could understand needing no external dependencies for a self-extractor stub, but I hadn’t thought that, for the kinds of applications you mention, having a few DLLs next to the EXE would be a deal-breaker.

(Whether downloaded as a Zip file or an installer, that’s how applications meant to run off flash drives or optical media work.)

No problem. 🙂

Well, there are some software solutions for which it is necessary to deploy a monolithic executable. These could be, for instance, utilities for forensic purposes, like evidence gathering. Having dependencies would be terrible if the solution needs to be made simple to deploy. Of course, with Qt DLLs it would be possible to write a self-extracting executable, but that wouldn’t be efficient neither in size nor performance. In some of these projects security and privacy are critical and building ones own compiler is quite common, for instance to introduce compiler-level obfuscation. That’s why this article should be seen more as a starting point for these kind of projects.

The -s thing you mentioned is interesting. To be honest I haven’t yet played much with Rust on Linux, but will keep this in mind when having to do so!

I agree it’s important to mention official ways. I wrote this article (code + text) in less than a day and not surprisingly forgot to mention certain aspects. I’ll elaborate in the article on the aspects you rightly mentioned in the upcoming days (as soon as I find some free time :).

First, I’d like to apologize. I just realized that I was probably subconsciously thinking of you as a script kiddie because you wrote that “a C++ developer can easily program in any C-dialect (Java, C#, Go, JS, etc.)”. (None of those languages are C dialects, any more than French is a dialect of Latin. Heck, French is more closely related to Latin than those languages are to C and it’s still not a dialect of Latin.)

That said, maintaining a patched in-house build of a compiler which sees releases every six weeks does still feel excessive to me, especially with the work done on --remap-path-prefix to cover the most glaring privacy leak.

Maybe I’m missing something, but, to me, it sounds like pouring in far too much effort for the reward you’ll get out out it, like executives spending massive sums to license DRM which just gets cracked within the first week anyway or technicians putting black tape over the status lights on the network switches in their data centers to protect customer privacy.

Also, I was a bit disappointed that you didn’t elaborate on why statically linking Qt was the only viable option, as opposed to dynamically linking against the LGPLed version.

Second, regarding my earlier comment, I experimented a bit and discovered that adding -C link-arg='-s' to RUSTFLAGS to strip build symbols on a GNU toolchain without a separate strip run can sometimes cause build failures depending on how the project is set up. The workaround is to compile the project with cargo rustc -- -C link-arg='-s' instead of relying on RUSTFLAGS.

You’re right about the compatibility for XP, it can be specified as option for the linker. I usually don’t care about this, because I run a post-build script to check for non-XP-compatible APIs and provide an emulation layer for them as described in one of my previous articles.

The reason I advise the linker option is that it’s always good practice to encourage people toward the officially supported option, since that’s what gets the testing and what any new team member or potential successor will be more familiar with, regardless of how much infrastructure you’ve built for verifying that the output is still correct. Otherwise, it’s like gratuitous use of unsafe just because you find the Rust idioms unappealing in some way. (And someone is liable to wander in off Google who won’t be as thorough as you.)

It’s true that there’s a linker option to stop the generation of debug information. I don’t use that option simply because if for some reason there’s a crash, the user can send me the crash dump and I have a PDB (debug symbols) to work with for the release executable. So if I just strip the debug path as a post build step, I don’t lose this capability. I always do that for all my builds, no matter the language. But the removal of the debug path is just a side-note in the article, not the main topic and the script for it is like 10 lines of code, so not really a big effort there. 🙂 However, I should have pointed out the reason for doing this.

You’re right about the compatibility for XP, it can be specified as option for the linker. I usually don’t care about this, because I run a post-build script to check for non-XP-compatible APIs and provide an emulation layer for them as described in one of my previous articles. But it’s good to point it out!

Yes, why not. 🙂 Thank you for pointing it out.

For the MSVC version of the Windows toolchain, see this thread.

(And, if you ever decide to use the GNU version of the Windows toolchain, add -C link-arg='-s' to your RUSTFLAGS or run strip on the binary after compiling it. (You can find an EXE-capable copy of strip in MinGW or Cygwin.)

As for targeting Windows XP, the proper way is to ask for it in the linking phase by passing through /SUBSYSTEM:CONSOLE,5.01.

I don’t have a Windows machine handy to confirm, but I think the proper way to do what you wrote in this blog post is to set RUSTFLAGS to -C link-args="/DEBUG:NONE /SUBSYSTEM:CONSOLE,5.01".