Compilation model (proposal)

cargo-gccrs invokes gccrs once with -fPIC to get the crate metadata, an object file, an assembly file, ... as necessary/requested. For all emit types except link, the respective file generated by gccrs is directly passed to the user. For link depending on the crate type(s) one of more of the following will be done:

• bin: Gcc will be invoked with the right arguments to link the final executable.
• lib/rlib: The crate metadata, object file and if necessary LTO metadata are packaged in a single archive.
• dylib: Gcc will be invoked with the right arguments to link a dylib with all symbols exported and the crate metadata embedded in the dylib.
• cdylib: Gcc will be invoked with the right arguments to link a dylib with only #[no_mangle] symbols exported and crate metadata not embedded.
• staticlib: The object file combined with the object files of all dependencies (rust and native archives) will be bundled in a single archive without crate metadata.
• proc-macro: Gcc will be invoked with the right arguments to link a proc-macro. (will have to wait until gccrs supports proc macros)

Gccrs will then have to learn how to read crate metadata from rlibs and dylibs.

This proposal should solve the problem of having to invoke gcc multiple times when using multiple crate types or when using --emit obj,link or something like that. It is also somewhat close to what rustc internally does except that some logic is moved from rustc_codegen_ssa::back::link to cargo-gccrs. It may also be possible to implement this logic in the gcc driver so you have for example -frust-crate-type=bin,lib,dylib.

--

@bjorn3

(originally from Rust-GCC/cargo-gccrs#34)