linking a rust_binary that depends on two cc_libraries with the same name fails

[krasimirgg]

This depends on #825. In particular, trying out this example without #825 will run into the linker errors described there and this example assumes using at least the beta rustc. I'm using Linux with ld.

Consider a case where a rust_binary (transitively) depends on two cc_libraryes that have the same name. In the wild targets with common names like utils, or status could occur in unrelated packages.

Like in this example where //same_names:rbin depends on //same_names/x:exc and //same_names/y:exc:

same_names
├── BUILD
├── rbin.rs
├── x
│   ├── BUILD
│   └── exc.cc
└── y
    ├── BUILD
    └── exc.cc

# same_names/BUILD
load("@rules_rust//rust:defs.bzl", "rust_binary")

rust_binary(
    name = "rbin",
    srcs = ["rbin.rs"],
    deps = [
        "//same_names/x:exc",
        "//same_names/y:exc",
    ],
)

// same_names/rbin.rs
use std::os::raw::c_int;

extern "C" {
    pub fn cx() -> c_int;
    pub fn cy() -> c_int;
}

fn main() {
    println!("hi {} {}", unsafe { cx() }, unsafe { cy() });
}

# same_names/x/BUILD
package(default_visibility = ["//visibility:public"])

cc_library(
    name = "exc",
    srcs = ["exc.cc"],
)

// same_names/x/exc.cc
extern "C" int cx() {
  return 17;
}

# same_names/y/BUILD
package(default_visibility = ["//visibility:public"])

cc_library(
    name = "exc",
    srcs = ["exc.cc"],
)

// same_names/y/exc.cc
extern "C" int cy() {
  return 113;
}

Running bazel build //same_names:rbin fails with a linker error like:

bin::main: error: undefined reference to 'cy'

The problem is that the way we construct linker command line arguments for native dependencies doesn't work when they have the same name. For each transitive native dependency, we pass its package directory as -Lnative= and its name as -lstatic= to rustc. These get translated to -Lpackage and -lname linker arguments. In the example above, the rustc arguments are like:

...
 '-Lnative=bazel-out/k8-fastbuild/bin/same_names/x'
 '-Lnative=bazel-out/k8-fastbuild/bin/same_names/y' 
 '-lstatic=exc' 
 '-lstatic=exc'
...

and get translated as linker arguments like:

...
 '-Lbazel-out/k8-fastbuild/bin/same_names/x'
 '-Lbazel-out/k8-fastbuild/bin/same_names/y' 
 '-lexc' 
 '-lexc'
...

Now the problem is that the linker always picks up the first libexc.a library that it finds on the path, in this case same_names/x/libexc.a, and hence the undefined reference errors for the symbol defined in same_names/y/libexc.a.

The way cc rules deal with this is that they just pass the full path to the library to the linker, AFAIK. I think this is a good way to address this and potentially some other naming incompatibilities across cc and rust rules.

Under the native-link-modifiers RFC, the relative order of -l and -Clink-arg(s) is preserved, so it should be OK to replace the current linker args pattern:

...
 '-Lnative=bazel-out/k8-fastbuild/bin/same_names/x'
 '-Lnative=bazel-out/k8-fastbuild/bin/same_names/y' 
 '-lstatic=exc' 
 '-lstatic=exc'
...

with something like:

...
 '-Clink-arg=bazel-out/k8-fastbuild/bin/same_names/x/libexc.a'
 '-Clink-arg=bazel-out/k8-fastbuild/bin/same_names/y/libexc.a'
...

[krasimirgg]

We've got some issues with the approach from #841, rooted in that the relative order of linker args derived from rustc -l and -Clink-arg(s) is not preserved, e.g., #841 (comment).

Longer term we hope that the native_link_modifiers rustc RFC rust-lang/rust#81490 will give us the necessary options to preserve the relative order.

For now the plan is to logically revert #841, so rules_rust goes back to use -lstatic for native dependencies. As a follow-up, we plan to address the issues with ambiguous native libraries (this issue) by constructing disambiguating symlinks. I'll hold up until #1134 is merged since the disambiguating symlinks feature touches much of the same code.