Implement archiver functionality internally?

[madsmtm]

Mentioned in here, seems that the system archiver can't always handle cross-compilation very well.

Dunno how difficult that would be, and whether we should instead make it easier to just pass .o files directly to the linker instead.

[bjorn3]

If you want to support LTO for the C code, then you did need to link against LLVM for this to get the symbol table from the bitcode files to put in the symbol table of the archive that is produced.

[nagisa]

LTO for C code is already somewhat troublesome in that for it to work cross-language, you need to somewhat match the versions of LLVM used by the C toolchain with what's used by rustc. If the archiver needs to be clang/llvm-ar, then IMO the best way to indicate that is via some sort of AR based environment variable (similar to how CC indicates the C compiler.) And then the default could be something builtin that transparently "just" works.

Of course the downside would be that every use of cc would then also build an archiver, but the archiver crate that exsits right now is relatively fast to build, and alternatively cc could also perhaps embed something more straightforward too.

[bjorn3]

A quick search shows multiple projects that enable LTO for the C side without doing cross-language LTO. That works with any random C toolchain that supports LTO at all. Doesn't matter if it is an LLVM version matching rustc or not.