Compiling a cdylib crate depending on some dylib crates does not reexport their symbols

It seems somewhat like #50007 strikes again?

Reproduction:

$ git clone https://gist.github.com/lf-/6ee8a527027b16d82b53137750c3e8b2 repro
$ cd repro
$ sh build.sh
$ nm -g libcrabmul.so
00000000000010f0 T crabmul
                 w __cxa_finalize
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U __rust_alloc
                 U __rust_alloc_zeroed
                 U rust_begin_unwind
                 U __rust_dealloc
                 U rust_eh_personality
0000000000000000 N rust_metadata_crabmul_1390237220c2291d
                 U __rust_realloc

$ nm -g libtoplevel.so
                 w __cxa_finalize
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable

I am trying to build a cdylib to link to C++ that uses other dylibs (since there are multiple C++ dylibs which each need a corresponding Rust cdylib to not break the C++ dependency hierarchy horribly). In doing this, it would be useful to be able to publicly export functions from the linked dylibs, which pub use is allegedly supposed to work for, but I am observing it not working.

I tried this code:

meowcrab.rs (dylib):

#[no_mangle]
pub extern "C" fn crab_add(a: u32, b: u32) -> u32 {
    a + b
}

crabmul.rs (dylib):

#[no_mangle]
pub extern "C" fn crabmul(a: u32, b: u32) -> u32 {
    a * b
}

toplevel.rs (cdylib):

pub use crabmul::crabmul;
pub use meowcrab::crab_add;

build.sh:

(note, this is very lightly edited from meson's generated build plan, you can probably delete like half the flags)

sysroot_lib=$(rustc +nightly --print sysroot)/lib
rustc +nightly -C linker=clang --crate-type dylib --edition=2021 -g -v --crate-name meowcrab --emit link=libmeowcrab.so --out-dir libmeowcrab.so.p -C metadata=meowcrab@sha -C prefer-dynamic meowcrab.rs
rustc +nightly -C linker=clang --crate-type dylib --edition=2021 -g -v --crate-name crabmul --emit link=libcrabmul.so --out-dir libcrabmul.so.p -C metadata=crabmul@sha -C prefer-dynamic crabmul.rs
rustc +nightly -C linker=clang --crate-type cdylib --edition=2021 -g -v --crate-name toplevel --emit link=libtoplevel.so --out-dir libtoplevel.so.p -C metadata=toplevel@sha --extern meowcrab=libmeowcrab.so --extern crabmul=libcrabmul.so -L. -C prefer-dynamic -C "link-arg=-Wl,-rpath,\$ORIGIN/:$sysroot_lib" -C link-arg=-Wl,-rpath-link,.:"$sysroot_lib" toplevel.rs

I expected to see this happen: I would expect to see the exported symbols exported from libtoplevel.so.

Instead, this happened: The exported symbols are not re-exported from libtoplevel.so in spite of the fix to #50007 seemingly saying they are intended to be.

Meta

rustc --version --verbose:

rustc 1.82.0-nightly (ca5d25e2c 2024-08-09)
binary: rustc
commit-hash: ca5d25e2c41f5a6b4ce65c681bf2f94c7ead1f14
commit-date: 2024-08-09
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

Clone the linked reproduction and run build.sh, then inspect meowcrab.rs, crabmul.rs, and toplevel.rs alongside the nm output for libcrabmul.so and libtoplevel.so. Compare the observed cdylib linking behavior with the expectation described in the issue and determine whether a compiler regression test is needed. Done means the intended re-export behavior is reproduced and covered by a confirmed fix or regression test.