rules_rust `cc_common_link` is broken in rust `1.87.0`

Compiling with cc common link is gives the following error when using rust 1.87.0

ERROR: /home/abe/.cache/bazel/_bazel_abe/827f63e25b315dd064e3058497da15dd/external/rules_rust+/util/process_wrapper/BUILD.bazel:31:36: Linking external/rules_rust+/util/process_wrapper/process_wrapper [for tool] failed: (Exit 1): gcc failed: error executing CppLink command (from target @@rules_rust+//util/process_wrapper:process_wrapper) /usr/bin/gcc @bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust+/util/process_wrapper/process_wrapper-0.params

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
ld.lld: error: undefined symbol: __rustc::__rust_dealloc
>>> referenced by alloc.rs:113 (library/alloc/src/alloc.rs:113)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(core::ptr::drop_in_place$LT$alloc..string..String$GT$::h1891d42eb8d68d4d) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a
>>> referenced by gimli.16f37c71821a4789-cgu.0
>>>               gimli-0242466ae973a482.gimli.16f37c71821a4789-cgu.0.rcgu.o:(alloc::collections::btree::node::Handle$LT$alloc..collections..btree..node..NodeRef$LT$alloc..collections..btree..node..marker..Mut$C$K$C$V$C$alloc..collections..btree..node..marker..Leaf$GT$$C$alloc..collections..btree..node..marker..KV$GT$::split::h9f8b8b63bff91341) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-0242466ae973a482.a
>>> referenced by alloc.rs:113 (library/alloc/src/alloc.rs:113)
>>>               panic_unwind-9832433a93414fcc.panic_unwind.bd2a812479e30d2d-cgu.0.rcgu.o:(core::ptr::drop_in_place$LT$panic_unwind..imp..Exception$GT$::h6802c1014e463d96) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-9832433a93414fcc.a
>>> referenced 1040 more times

ld.lld: error: undefined symbol: __rustc::__rust_realloc
>>> referenced by alloc.rs:133 (library/alloc/src/alloc.rs:133)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(alloc::raw_vec::finish_grow::hbf22bc34c9e458e7) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a
>>> referenced by gimli.16f37c71821a4789-cgu.0
>>>               gimli-0242466ae973a482.gimli.16f37c71821a4789-cgu.0.rcgu.o:(alloc::raw_vec::finish_grow::hafdb4f4925013357) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-0242466ae973a482.a
>>> referenced by alloc.rs:133 (library/alloc/src/alloc.rs:133)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(alloc::ffi::c_str::CString::_from_vec_unchecked::h6fd1f8c4256369f7) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a
>>> referenced 15 more times

ld.lld: error: undefined symbol: __rustc::__rust_alloc
>>> referenced by mod.rs:0 (library/alloc/src/raw_vec/mod.rs:0)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(alloc::raw_vec::finish_grow::hbf22bc34c9e458e7) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a
>>> referenced by alloc.rs:93 (library/alloc/src/alloc.rs:93)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(_$LT$$RF$str$u20$as$u20$alloc..ffi..c_str..CString..new..SpecNewImpl$GT$::spec_new_impl::he67d371a567108ea) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a
>>> referenced by alloc.rs:93 (library/alloc/src/alloc.rs:93)
>>>               panic_unwind-9832433a93414fcc.panic_unwind.bd2a812479e30d2d-cgu.0.rcgu.o:(__rustc::__rust_start_panic) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-9832433a93414fcc.a
>>> referenced 140 more times

ld.lld: error: undefined symbol: __rustc::__rust_alloc_error_handler
>>> referenced by alloc.rs:405 (library/alloc/src/alloc.rs:405)
>>>               alloc-c7b16bb34ad937e6.alloc.4810a64b00f2b3b7-cgu.0.rcgu.o:(alloc::alloc::handle_alloc_error::he8b8c0d2be2abab7) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-c7b16bb34ad937e6.a

ld.lld: error: undefined symbol: __rustc::__rust_alloc_zeroed
>>> referenced by gimli.16f37c71821a4789-cgu.0
>>>               gimli-0242466ae973a482.gimli.16f37c71821a4789-cgu.0.rcgu.o:(alloc::raw_vec::RawVecInner$LT$A$GT$::try_allocate_in::h6fcaf43c21d8069d) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-0242466ae973a482.a
>>> referenced by alloc.rs:176 (library/alloc/src/alloc.rs:176)
>>>               std-769ac7a9899f22f3.std.ab9b65b5f5dd2f44-cgu.0.rcgu.o:(std::backtrace_rs::symbolize::gimli::stash::Stash::allocate::h4ab823c4eb5e69be) in archive bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++rust+rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-769ac7a9899f22f3.a
collect2: error: ld returned 1 exit status
Target //:main failed to build

I am guessing it is caused by https://github.com/rust-lang/rust/pull/127173. Minimized example is available at https://github.com/abezukor/rules_rust/tree/55db7d8bfdcdfac0b1627dcdc3b2066d81f356d6

Jun 02 '25 20:06 abezukor

Right, that's the root cause. I've been slowly working on an approach to fix this up in https://github.com/bazelbuild/rules_rust/pull/3403. Unfortunately it's a bit complex, not ready yet, and will only work with a nightly version of rustc (as it relies on unstable features of rustc to mangle the rust stuff).

Jun 03 '25 09:06 krasimirgg

This is affecting us as well now, as we would like to update https://github.com/github/codeql to use 1.88 (which is required by the latest version of rust-analyzer). Any hope that https://github.com/bazelbuild/rules_rust/pull/3403 could be merged any time soon?

Jul 07 '25 13:07 redsun82

Or is there any known workaround? We aren't averse to patching rules_rust, so we could also just take https://github.com/bazelbuild/rules_rust/pull/3403 in as a patch...

Jul 07 '25 13:07 redsun82

Ah, I've seen https://github.com/bazelbuild/rules_rust/pull/3403 got merged, thanks for the work on that! When can we expect a new release with that in?

Jul 09 '25 13:07 redsun82

When can we expect a new release with that in?

Since it's a big change and the rust toolchain has evolved a bit since, I'd like to let it bake for a week or so and integrate it into a few of our internal workflows to fish to potential issues before we cut a new release. redsun82 would it be feasible for you to try it out in your repository before a release cut?

Jul 09 '25 13:07 krasimirgg

Yeah, I think I can try that

Jul 09 '25 14:07 redsun82

When can we expect a new release with that in?

Since it's a big change and the rust toolchain has evolved a bit since, I'd like to let it bake for a week or so and integrate it into a few of our internal workflows to fish to potential issues before we cut a new release. redsun82 would it be feasible for you to try it out in your repository before a release cut?

When trying to build with the change on a large code base including lots of Rust and C++ code in one binary, experimental_use_allocator_libraries_with_mangled_symbols works for me when using nightly/2025-05-13 (added with Rust 1.87.0). However, the build fails with nightly/2025-07-09 where lld complains about __rustc::__rust_no_alloc_shim_is_unstable_v2 not being defined – perhaps mangling needs to be fixed for more symbols with later Rust versions?

Jul 10 '25 08:07 fhanau

Thank you! There were new internal symbols added in the meantime. Looking into it.

Jul 10 '25 11:07 krasimirgg

Fixes for recent nightly versions of the rust toolchain are available in release 0.63.0.

Users need to opt-in by using --//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols; see https://github.com/bazelbuild/rules_rust/pull/3403#issue-2984787431 for more details.

Unfortunately, we don't have a workaround for non-nightly versions of the toolchain at this time, since the workaround relies on unstable rustc features.

Jul 24 '25 05:07 krasimirgg

After updating to the recent nighttly toolchain we observed significantly worse linking performance. To be specific the time to link increased from somewhere around 4 seconds to more than 160 seconds. Unfortunately I was unable to test whether removing --@rules_rust//rust/settings:experimental_use_allocator_libraries_with_mangled_symbols=true would help since we get linker errors without it. The performance degradation is only observed when generation of Apple debug symbols is enabled using --apple_generate_dsym --output_groups=+dsyms.

Sep 15 '25 12:09 adincebic

I believe @mikea and I found a relatively elegant workaround for using cc_common_link that doesn't require nightly Rust: Instead of supplying the allocator symbols using nightly mangling or by using rustc for linking, we can also get them by defining a rust_static_library target with no dependencies and an empty lib.rs file. This results in a rustc-built static library being built that contains the empty library, but also all rust libraries it may depend on including the rust standard library and the required allocator symbols. One wrinkle is that this can result in the allocator libraries being linked twice based on the ones rules_rust would add on its own – to work around that we can set allocator_library = ":rust-allocator" in rust_register_toolchains(), where rust-allocator is an empty cc_library target. I'm sure that with slight changes to rules_rust this can be made more elegant so that no empty target is required. If binaries that include Rust code are linked with that static library as a dependency, they will have all the required symbols even when using cc_common_link with a recent Rust version. We have this working with Rust 1.91.0 in our project.

Nov 16 '25 18:11 fhanau

I'd be happy to review a pull-request for this if @krasimirgg is not available!

Nov 17 '25 17:11 UebelAndre

FYI i'm having different undefined symbols using cc_common.link

Undefined symbols for architecture arm64:
  "_bytes[abfcfd50af4c0a09]::panic_advance", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::string::merge::<&mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::varint::decode_varint_slow::<&mut &[u8]> in protoc_wrapper.o
  "_<prost[4d61f58e379b6624]::error::DecodeError>::push", referenced from:
      _protoc_wrapper[bfaff4a64cac203e]::main in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
      ...
  "_<bytes[abfcfd50af4c0a09]::bytes_mut::BytesMut>::reserve_inner", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
  "_bytes[abfcfd50af4c0a09]::bytes_mut::rebuild_vec", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
  "_bytes[abfcfd50af4c0a09]::bytes_mut::SHARED_VTABLE", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
  "_<bytes[abfcfd50af4c0a09]::bytes::Bytes as core[4f7d58dda14e06a2]::convert::From<alloc[2c976890ba3260a7]::vec::Vec<u8>>>::from", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o
  "_<prost[4d61f58e379b6624]::error::DecodeError as core[4f7d58dda14e06a2]::fmt::Debug>::fmt", referenced from:
      l_anon.cdc4edc3d2b16e50ba89fbf7defac048.240 in protoc_wrapper.o
  "_<bytes[abfcfd50af4c0a09]::bytes_mut::BytesMut as core[4f7d58dda14e06a2]::ops::drop::Drop>::drop", referenced from:
      _prost[4d61f58e379b6624]::encoding::message::merge_repeated::<prost_types[f3b35e52838edb33]::protobuf::UninterpretedOption, &mut &[u8]> in protoc_wrapper.o

Nov 20 '25 18:11 cerisier