Enable rlib-only libstd build (no dylib)

[RalfJung]

For cross-building libstd (for use e.g. with miri), it would be great if one could make an rlib-only libstd build. This is because building a dylib invokes the native linker, and that fails when the target architectures is too foreign and/or not supported by the installed C toolchain. (Currently, we build libstd both as rlib and dylib.)

So my goal was to equip libstd with a feature flag to control whether it is built as a dylib (next to the rlib) or not. To this end, I patched collect_crate_types such that the crate types passed on the command-line and the one given as attributes are merged (instead of command-line taking precedence). That means I can use #![cfg_attr(dylib, crate-type = "dylib")] to make a dylib feature enable a dylib build. That seems to work, however, there is a problem: During bootstrap, rustbuild uses cargo's stamp file to determine which files to copy into the sysroot, and that stamp file now no longer includes the libstd.so, breaking the build.

I wonder if there is maybe a better way to achieve an rlib-only libstd build?

Cc @eddyb @alexcrichton any advice?

[eddyb]

cc @rust-lang/compiler This interaction between CLI flags and attributes seems really unfortunate.
I wonder if Cargo could benefit from a --print option for this, that would be handled after macro expansion, but it would have to happen at the same time as compiling the crate (as to avoid doing parsing and expansion twice), so it'd be more like --emit=dep-info.

[alexcrichton]

This is currently a limitation of the compiler and we can't conditionally produce a dynamic library. The CLI flags passed to rustc trump whatever is listed in the crate (attribute-wise), and there's no way to have Cargo conditionally produce a dynamic library for the standard library, unfortunately.

We could consider adding a feature to rustc for this though! (it's certainly been asked for before)

[RalfJung]

@alexcrichton I have a branch that makes CLI flags not trump attributes any more.

The problem is, as described in my first post: With that patch, rustbuild no longer copies the libstd.so into the sysroot because it is not listed in the stamp file.

[alexcrichton]

Yeah crate type is tricky where it can't really be configured without Cargo's knowledge as Cargo moves around files and need to know what's being output. I think this would need to be a Cargo feature rather than a rustc feature to implement this

[RalfJung]

@alexcrichton suggested it might be possible to do at least a metadata-only build, using essentially cargo check.

I tried this, but at least for cross-building purposes that currently does not work because since compiler_builtins got moved out of the rustc workspace, the c feature is forced to be enabled. (It can be controlled in libstd, but not in liballoc which sets rustc-dep-of-std.)