Extensionless static libraries from WASM allocator libraries breaks `determine_lib_name`

[cameron-martin]

Since #3864, the allocator libraries are now static libraries. WASM toolchains have a staticlib_ext as the empty string. This breaks a check in determine_lib_name. How to fix this is not that clear:

1. Are static libs for WASM valid?
2. If so, is the empty extension valid or should they be e.g. .a?

[UebelAndre]

This is a great question I don't think the current maintainers have context on. Maybe @PiotrSikora or @phlax can provide some insight?

[PiotrSikora]

@UebelAndre I have no context here, but both main and v0.69.0 (that contains #3864) work fine for my rust_shared_library builds.

@cameron-martin could you share the error and ideally a reproducer (can be just your project if it's open source)?

[cameron-martin]

Here is a repro: archive.tar.gz

Running bazel build results in the following error:

Error in fail: Unknown crate_type: `staticlib`. If this is a cargo-supported crate type, please file an issue!

This error is hit because it goes down this branch, but for WASM toolchains the staticlib_ext is the empty string.

My example uses --@rules_rust//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols=True, but it likely happens any time we're both targeting wasm and the allocator library is explicitly linked, rather than relying on rustc to implicitly add it.

[PiotrSikora]

My example uses --@rules_rust//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols=True, but it likely happens any time we're both targeting wasm and the allocator library is explicitly linked, rather than relying on rustc to implicitly add it.

I have no idea about that experimental flag (cc @krasimirgg), but your example builds fine without it, even after I added wee_alloc as #[global_allocator].

[cameron-martin]

I have no idea about that experimental flag (cc @krasimirgg), but your example builds fine without it, even after I added wee_alloc as #[global_allocator].

This is the easiest way to trigger it, but I also suspect it happens when using the cc linker to link rust code (rather than rustc), either by having a cc_binary depend on a rust_library or by using --@rules_rust//rust/settings:experimental_use_cc_common_link. When linking in this manner, an extra library is inserted into the dependency graph to emulate a library that rustc implicitly adds when used as the linker. It is building this extra library that fails when the target is wasm. Changing the global allocator via the rust attribute was not what I meant by "the allocator library is explicitly linked".

It's not trivial to set up a wasm cc toolchain, however, so reproducing through this route would be more effort.

[cameron-martin]

Actually I think I'm wrong here. This path does seem to be only hit when using this experimental flag:

rules_rust/ffi/rs/BUILD.bazel

Lines 18 to 25 in e4a4fb6

	alias(
	name = "default_allocator_libraries",
	actual = select({
	"@rules_rust//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols_on": ":allocator_libraries_with_mangling_support",
	"//conditions:default": ":empty_allocator_libraries",
	}),
	visibility = ["//visibility:public"],
	)

I'm slightly confused about how these symbols get linked in the two cases I mentioned above.

[UebelAndre]

I feel like #3892 will fix the issue. There are some implicit deps to rules that still seemed to cause issues which I had to fix to get this change working.

[cameron-martin]

Which part of #3892 were you thinking would fix it? I had a scan through but couldn't see anything likely.

However, I think I have an answer to my original questions: Yes, static libraries are valid for wasm and they're just .a files. So, I think the solution to this is to update here to make the extensions .a.

[UebelAndre]

Which part of #3892 were you thinking would fix it? I had a scan through but couldn't see anything likely.

https://github.com/bazelbuild/rules_rust/pull/3892/changes#r2915141800

[UebelAndre]

There is obviously still the open question about how staticlib_ext should be handled but this should save some folks from some failures with the same signature

[cameron-martin]

Which part of #3892 were you thinking would fix it? I had a scan through but couldn't see anything likely.

https://github.com/bazelbuild/rules_rust/pull/3892/changes#r2915141800

I see. Does that path get hit even when --@rules_rust//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols is enabled?