Skip to content

Native link flags repeat when a binary and its library share a build script #4291

Description

@jrandolf

Description

A common package shape gives both a rust_library and its rust_binary the same cargo_build_script dependency. If the script emits cargo:rustc-link-lib, rules_rust applies the native library flags to the library and also passes the script's .linkflags file directly to the binary. The binary already receives that native linkage through the library.

The library should own those native link directives when the binary depends on it. A standalone binary that uses the script still needs the directives itself.

Reproduction steps

The fixture in #4276 defines this dependency graph:

lib             -> shared_script
bin_with_lib    -> lib, shared_script
bin_without_lib -> shared_script

The script emits a native system-library directive (c on Unix, kernel32 on Windows). Inspect the Rustc actions for references to shared_script.linkflags:

Target Expected direct flag-file count Before the fix
lib 1 1
bin_with_lib 0 1
bin_without_lib 1 1

Add the fixture directory to the affected revision, leaving the production rule unchanged, then run:

bazel test //cargo/tests/cargo_build_script/duplicate_link_flags:all

The bin_with_lib_link_flags_test assertion exposes the redundant direct input; the other two cases guard the required propagation.

Additional context

Proposed fix: #4276. It checks whether a direct library dependency already uses the same build-script provider before attaching that script's native link flags to the consuming crate.

Impact

Packages with a library and binary get redundant native library arguments. The fix needs to preserve library and standalone-binary linkage and compare the build-script providers.

Bazel and rules_rust version

Affected rules_rust revision: c708b236. The existing regression work used Bazel 9.2.0 on macOS arm64.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    awaiting-responseMaintainers have responded to the pull-request or thread and now await contributor responses.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions