Corrode does not produce .o files, halting build systems

[eternaleye]

As the corrode tool currently does not produce a .o file, buildsystems which rely on that (or the -o flag) currently halt very quickly with an error. Producing anything would be better than nothing, and the following might be palatable options:

1. Simply drop an empty file there. This is unlikely to work well, but it's quite easy
2. Drop an object file that has no contents (and thus can be constant data in corrode) into place
3. Invoke rustc on the generated .rs file
4. Some combination of 2 and https://github.com/jameysharp/corrode/issues/54 - akin to LLVM's ThinLTO
5. Some combination of 3 and https://github.com/jameysharp/corrode/issues/54 - akin to "classic" LTO, that both generates normal code and also permits the linker to throw it away and start over.

[jameysharp]

I've been doing my tests with make -k, to make it compile as many different source files as possible despite the previous commands "failing" to produce the expected .o files. That's worked great for as far as I've gotten on any real code so far.

That said, I like the idea of one of your plans coupled with #54, which I'd been wanting anyway.

I think my favorite option is as follows. When compiling with -c:

• Try to emit a .rs file, then try to run rustc --crate-type=lib or something on the result and extract the .o file from that.
• If either of those steps fails, run the regular C compiler with the same arguments that were passed to Corrode, and get a .o file from there.

Without -c, use whatever solution from #54 to combine any previous output. Collect all the .o files that have corresponding .rs files into a single crate, generating a top-level lib.rs re-exporting everything that was public. Collect the other .o files into a static library using the system native toolchain and tell Rust to link that into the generated crate.

There are a lot of fiddly details there, but if we can pull that off I think the result will be quite nice. It should allow fully building existing projects like musl libc even when we can't translate every source file, and should allow using those projects' existing test suites to verify that the translation came out right.

[jameysharp]

I've committed a script that does this almost correctly (scripts/corrode-cc). You can use it in place of gcc. It will try to run Corrode plus rustc and massage the result into a .o file, but if that fails for whatever reason it'll fall back to gcc.

The current committed version produces .o files that need extra stuff to link correctly. I have a revised version that embeds the entire Rust standard library in the .o file, which links correctly but of course it produces very large output... I have a musl-libc build that's 851MB, for example, because it has 200 copies of the Rust standard library. Whoops.

So there's some more work to be done here to get a reasonable .o file out, but it kind of works now!