bazelbuild / bazelbuild/rules_cc
How to encode bare (system) link libs and flags for none C++ toolchains
- Dominant language
- Starlark
- Stars
- 247
- Forks
- 196
- PR merge metrics
- No merged PRs in 30d
Description
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.
What I think might be better:
```python
cc_common.create_linker_input(
owner = ctx.label,
libraries = depset([my_new_library]),
system_link_libraries = depset(["pthread", "dl", "resolv"])
)
```
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.
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.
Contributor guide
Assessment
This issue has not been assessed yet.