rust: Use `--print native-static-libs` to collect dependencies of staticlib library targets

[sdroege]

Currently meson requires listing dependencies of staticlib library targets manually, which is error prone at best. The correct way would be to let rustc provide these dependencies via the --print native-static-libs commandline parameter.

Unfortunately this requires putting a wrapper around rustc for this case and parsing something from stdout. Also unfortunately it's placed in between any other output.

The output is for example

note: Link against the following native artifacts when linking against this static library. The order and any duplication can be significant on some platforms.

note: native-static-libs: -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc

[xclaesse]

I'm wondering if we could get away with doing that only once when doing rustc sanity checks with an empty lib.rs. Other than the few libs needed for Rust std, Meson already knows all dependencies.

[sdroege]

I don't think so. Theoretically this should be based on what is actually used by the code, but that doesn't seem to be the case right now.

So for example if you had

#[no_mangle]
pub extern "C" fn my_staticlib_add(left: i32, right: i32) -> i32 {
    unsafe {
        g_free(0 as _);
    }
    left + right
}

#[link(name = "glib-2.0")]
extern "C" {
    fn g_free(p: *mut ());
}

then it should print -lglib-2.0 too (but currently doesn't although e.g. a cdylib build of that links to it).

[xclaesse]

@sdroege but to compile that code you have to do static_library('foo', 'lib.rs', dependencies: dependency('glib-2.0')) so Meson knows libfoo needs glib, it does not need Rust to tell it. That's the same as for C/C++ libraries.

[sdroege]

@xclaesse Maybe a bad example. Instead of GLib, think of some Windows system library in that place. You wouldn't have a meson dependency for that as it's always available anyway.

[sdroege]

As discussed on IRC the main problem here is that meson requires this information at configure time, but printing this information happens as part of actually building the target.

So the best way forward here for now would be

1. Grab the std libraries by building a dummy.rs at configure time. That would solve the big majority of cases already.
2. Require other libraries to be explicitly listed as meson dependencies in the meson.build, and not just as #[link] attributes.
3. Figure out a way forward to adding this information to Cargo.toml of crates where this is required. The existing cargo link attribute is not suitable for this as in a build there can only be a single crate that specifies this attribute for a given library. E.g. Add support for declaring linkage to system/platform libraries gdesmott/system-deps#74

[eli-schwartz]

Is this not solved by #11790?

[bjorn3]

Not fully. That PR only adds the libraries used by the rust standard library, not those depended on using #[link(name = "...")] in user code afaict. The latter would require moving the --print native-static-lib usage to the rustc invocation that actually builds the final rust staticlib rather than using it on a dummy crate.

[eli-schwartz]

Hmm. Wouldn't that be equally well handled by moving build configuration out of source code pragmas (MSVC says hi!) and into meson.build dependency directives? :)

[bjorn3]

There are cases wher rustc needs #[link] specifief to produce correct object files (eg to determine if dllimport is necessary), at which point requiring meson configuration would cause duplicate work for the user. Also I don't know if meson wants to support using unchanged rust crates from crates.io, but if it does, supporting #[link] would reduce amount of work necessary to add a new dependency or updating an existing dependency. If not, this argument of course doesn't apply. I guess it is up to you to decide if you want to support it or not.