As part of bazelbuild/rules_rust#361 a minor challenge is presented. Presently the Rust standard library links to a number of system libraries on various platforms.
These are to get access to the obvious aspects of the underlying system since unlike golang Rust does not use syscalls for OS access.
Right now the additional flags are encoded as a list of platform to the flags that should be added to the linker. Using Linux as an example this means that to link a binary using a Rust library that itself uses std requires -lpthread and -ldl.
The challenge starts with toolchains that do not understand these link flags. For example on windows you can have a GNU toolchain which only understands unix style flags and not MSVC ones. Making the (probably incorrect) windows link libraries like w2_32.lib incorrect for that configuration.
Where system_link_libraries is able to plug into the rest of the toolchain rules around flag groups and actions and given plain libraries know how to generate the correct flags for the linker.
This is probably a little bit of a niche use case and does break hermetic properties of bazel somewhat, but would seem to be better than assuming the toolchain is the platform common toolchain and providing overrides via environment variables.
As part of bazelbuild/rules_rust#361 a minor challenge is presented. Presently the Rust standard library links to a number of system libraries on various platforms.
These are to get access to the obvious aspects of the underlying system since unlike golang Rust does not use syscalls for OS access.
Right now the additional flags are encoded as a list of platform to the flags that should be added to the linker. Using Linux as an example this means that to link a binary using a Rust library that itself uses
stdrequires-lpthreadand-ldl.The challenge starts with toolchains that do not understand these link flags. For example on windows you can have a GNU toolchain which only understands unix style flags and not MSVC ones. Making the (probably incorrect) windows link libraries like
w2_32.libincorrect for that configuration.What I think might be better:
Where
system_link_librariesis able to plug into the rest of the toolchain rules around flag groups and actions and given plain libraries know how to generate the correct flags for the linker.I suspect that a variant of this is what causes these sort of issues https://github.com/bazelbuild/rules_rust/issues/251
This is probably a little bit of a niche use case and does break hermetic properties of bazel somewhat, but would seem to be better than assuming the toolchain is the platform common toolchain and providing overrides via environment variables.