Description
So, I do a lot of cross compilation. I always set up my builds to do cross compilation to all targets from at least my computer if not from most common operating systems. I cross compile to lots of different systems and work with a lot of toolchains. I even "cross compile", routinely, even from an operating system to itself, such as from Linux to Linux due to wanting to run the binaries on an older version of a different distribution.
One of the things that has always been a pretty fundamental for effective and universal cross compilation is that the tools you are using aren't just "binaries": they are "commands". You can't just say "here's the compiler, treat it as gcc" or "here's the linker, treat it as ld"... you have to pass linker scripts, sysroot paths, runtime library configurations (for threading/exception mechanisms or to select a C++ standard library), binary paths (gcc and clang -B), weird flags to map paths in specialized embedded debugging information... lots of stuff.
This isn't just how I have ended up generalizing this problem: in the Firefox build system, they do the same thing... and they ran into the same problem I'm seeing, which is that cargo doesn't seem to think of cross compiling in this way. Their solution seems to have been to have a shell script "wrapper" that they pretend is a compiler/linker that passes extra arguments smuggled in via environment variables... which is 1) crazy indirect and 2) is difficult to make work correctly on Windows due to it being difficult to just "run a shell script" (which then became a documented limitation of the Firefox build system).
https://bugzilla.mozilla.org/show_bug.cgi?id=1329737
Instead of doing all of this, can there be some mechanism for just providing extra compiler/linker arguments? I would argue that a compiler/linker is always a command--like, maybe you want to use something like distcc, which is classically done by just setting the compiler to "/path/to/distcc /path/to/gcc", which already is fundamentally not going to work if the compiler is required to be a binary, and to point it out: this isn't even a "flag"... the path to the compiler at this point is the "flag" :(--but it at least needs to have a way to provide extra arguments.
The meson build environment also insists on modeling the compiler/linker as a binary, but it at least provides a way to throw in extra arguments in other variables (c_link_flags, for example), so maybe Cargo can do that? Then projects such as all of mine--and Firefox! ;P--will be able to do the flexible cross-compilation that we are used to, with custom toolchains and limited sysroots and new standard libraries... compiling should be fun ;P.