Add support for declaring linkage to system/platform libraries

[sdroege]

Examples of this would be e.g. the whole zoo of libraries Windows ships, like bcrypt.dll or kernel32.dll (the latter is already pulled in by std of course).

Having these listed in the Cargo.toml would help in case of building a staticlib as all these libraries will also have to be provided again when linking the final build result (executable or shared library). By having them listed in Cargo.toml they could be extracted from there for later usage.

See also https://github.com/mesonbuild/meson/issues/11789

[gdesmott]

I've never build anything on Windows but I trust you if you say such thing would be useful. :)

[sdroege]

On Linux you could imagine people making use of libm, libpthread, libdl, librt or things like that. Same story

[xclaesse]

It's not a Windows specific issue, Linux also have some extra system libs needed for Rust stdlib. See for example that Meson unit test: https://github.com/mesonbuild/meson/blob/master/test%20cases/rust/5%20polyglot%20static/meson.build.

[xclaesse]

With https://github.com/mesonbuild/meson/pull/11790 Meson can already add system libs for Rust std, but we still need a way to get extra libs from Cargo.toml for libs used with e.g. #[link(name = "bcrypt")] without requiring to compile that rust code to figure its dependencies. Meson will need them at configure time to use the staticlib built by rustc.

[xclaesse]

Adding to this topic, it would be nice to have the information when crate is built with no-std so Meson knows to not link with system libraries needed for Rust's std. I'm not sure it really fits system-deps design, but it's kind of related.

[nirbheek]

To add to what @xclaesse said, on Linux there's system libs like -lintl that need to be explicitly linked to.