bazelbuild / bazelbuild/rules_rust
proc-macro crate_type build fails with --force-pic
- Dominant language
- Starlark
- Stars
- 843
- Forks
- 651
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 15
Description
We, incorrectly or otherwise, been using --force-pic in our builds. This triggered a build failure with the following as a min repro:
WORKSPACE
```bazel
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_rust",
sha256 = "a3c6d6f8ddb6ba6dfc7cfdd274998153df8f2b057cd0cbb2bd5ca00a0f2bb9e5",
strip_prefix = "rules_rust-6267c267bee6bb869e381130b92922ee2c07e275",
urls = [
# main branch as of 2021-02-09
"https://github.com/bazelbuild/rules_rust/archive/6267c267bee6bb869e381130b92922ee2c07e275.tar.gz",
],
)
load("@rules_rust//rust:repositories.bzl", "rust_repositories")
rust_repositories()
```
BUILD
```bazel
load("@rules_rust//rust:rust.bzl", "rust_library")
rust_library(
name = "fails_with_force_pic",
srcs = ["lib.rs"],
crate_type = "proc-macro",
)
````
lib.rs (is empty)
```rust
```
When running with bazel 3.5.0, I see that:
```bash
bazel build --force_pic //... #fails
bazel build //... #works
```
Incidentally, we can still depend on a proc-macro target, and still build correctly. So I could, in theory, mark `fails_with_force_pic` with a `manual` tag, and still use any code in it just fine.
The only difference in the compilation step is that `-pie` is added to the link-args when --force-pic is enabled. This appears to be related to the use of `CPP_LINK_EXECUTABLE_ACTION_NAME` in [get_linker_and_args()](https://github.com/bazelbuild/rules_rust/blob/main/rust/private/rustc.bzl#L252-L264). Using [CPP_LINK_NODEPS_DYNAMIC_LIBRARY_ACTION_NAME](https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/cc/action_names.bzl#L68) doesn't add `-pie`, for example.
@hlopko, given the type of [extensions selected here](https://github.com/bazelbuild/rules_rust/blob/main/rust/private/rust.bzl#L48-L55), do you think that should be switch up based on crate type?
Contributor guide
Assessment
This issue has not been assessed yet.