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

[lf-]

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

[workingjubilee]

...huh.

[bjorn3]

#50007 is about a dylib exposing #[no_mangle] symbols from linked in rlibs, whose fix is to add those symbols to the version script such that the symbols are exported from the dylib rather than kept private. What you have here however requires re-exporting symbols of one dylib from another, which ELF doesn't support afaik. Nor is it really necessary for ELF as there is a single global namespace for all symbols, so even if you don't explicitly depend on meowcrab and crabmul, the dynamic linker will still find them (but the compile time linker doesn't, instead requiring you to pass -u crab_add -u crabmul to indicate that those symbols are expected to be undefined). For Mach-O re-exporting symbols is a thing and I think for COFF/PE it is too.