Consider building/linking run-make-support as a dylib instead of a static lib

[Zalathar]

While looking at the code that compiletest uses to build auxiliary crates as dylibs, it occurred to me that run-make tests could potentially benefit from linking to run-make-support dynamically.

This could perhaps result in less bloated rmake executables and faster builds/rebuilds, though that's pure conjecture as I haven't actually tried it. On the other hand, it's possible that the extra effort/complexity required to do so might not be worth it, especially if some of that complexity is in bootstrap.

[Zalathar]

I mostly wanted to make this issue to get the idea out of my head. It's a neat idea, but might not be worth spending time on.

[jieyouxu]

This is possible (though note that some targets don't support dynamic linking, but ig they can fallback to static in that case). run-make-support can also not be built as a stage0 tool lib, it can be built as a regular lib by stage N compiler for --stage N. It was implemented the way it is currently because that was the easiest at the time when I initially added it.

[bjorn3]

It should be a matter of adding [lib] crate-type = ["lib", "dylib"] to run-make-support/Cargo.toml and passing -Cprefer-dynamic to all rmake.rs compilations. This should seamlessly handle host triples where dylibs are not supported because cargo ignores crate types not supported by the target. It may be necessary to also explicitly pass -Cprefer-dynamic when compiling run-make-support.

[lolbinarycat]

isn't the lib crate type already basically dylib+staticlib? i'm not sure we don't just need -Cprefer-dynamic, tbh.

[bjorn3]

No, the lib crate types is an alias for the rlib crate type. You can't dynamically link an rlib. You need to use the dylib crate type for that. And in addition in the case of run-make-support we need the lib/rlib crate type to support targets that don't have dynamic linking support.