Generated libraries with the same name fail to link

[finn-ball]

If Rust tries to link against two generated libraries with the same name, there will be the error:

ld.lld: error: undefined symbol: app_function
          >>> referenced by app.1555d9328bfdc04c-cgu.0
          >>>               bazel-out/k8-fastbuild/bin/app.app.1555d9328bfdc04c-cgu.0.rcgu.o:(app::main::h288a2b8d569cac4d)
          collect2: error: ld returned 1 exit status

Possible breaking change introduced here: #3647

It's likely the depsets before allowed same name binaries to exist due to a nested structure.

Example which shows the breaking change along with workarounds:
https://github.com/finn-ball/rules_rust_binary_clash

[hofbi]

@dzbarsky FYI

[dzbarsky]

Thanks for the repro, I'll take a look when I have a bit of free time. My initial reaction is that linking multiple libs with the same name is not really well-supported (due to how -L and -l flags work) so I think this was working by accident - there's a ton of logic in rules_rust to try to deal with it for cdeps

rules_rust/rust/private/rustc.bzl

Lines 531 to 536 in aa6e74e

	def _disambiguate_libs(actions, toolchain, crate_info, dep_info, use_pic):
	"""Constructs disambiguating symlinks for ambiguous library dependencies.
	The symlinks are all created in a _ambiguous_libs/ subfolder specific to
	the target crate to avoid possible collisions with sibling crates that may
	depend on the same ambiguous libraries.

. But I suspect that doing your cc builds inside a build script bypasses all that logic. So perhaps another way to solve your issue is to use cc_library to build C code instead of build scripts - that generally performs a lot better as well, build scripts are pretty hacky and I wouldn't recommend using them for first-party code, only to make existing -sys crates work. (And also maybe build_script_runner can emit full paths to libraries that should be linked instead of using -L/-l which are ambiguous?)

[UebelAndre]

Should that change be reverted? It was just a performance optimization right?

[dzbarsky]

I'm not opposed to reverting if we think this is causing friction/breakage to the ecosystem, but it sounds like the one case that hit it so far was doing something quite unusual (multiple build scripts for a single crate) and had a pretty trivial workaround, so perhaps it's worth keeping in the perf optimization that helps everyone until we see if there's more complaints?

[hofbi]

I am ok keeping this change. We might want to add a warning for the user about the naming collision.