Compiling to Shared Library doesn't always expose reexported symbols

[CryZe]

Consider the following:

We have 2 crates, rlib helper and the shared library foo that depends on the helper crate. The helper crate's lib.rs looks like this:

#[no_mangle]
pub extern fn bla() -> i32 {
    5
}

The shared library's lib.rs looks like this:

extern crate helper;

pub use helper::bla;

The code is then compiled to a shared library. The bla symbol is not exported. That does not seem intentional.

[dbrgn]

Maybe a duplicate of #36342?

[thomcc]

It's not a duplicate of #36342, which is about reexporting functions defined in C AFAICT. We've been struggling with this in https://github.com/mozilla/application-services.

This doesn't seem to happen with all targets. In particular, x86_64-apple-darwin seems unaffected, while i686-linux-android is effected (really all android targets seem to be affected).

I have a simple reproducable case at https://github.com/thomcc/megazord/tree/simple-bug-repro (e.g. the simple-bug-repro branch of that repository). An explanation for how to use it to reproduce the issue is in the README.md.

It's worth noting that if you turn on LTO, the issue does not manifest (all symbols are present), presumably due to it being a single compilation unit at that point (thanks to the reporter for pointing this out to me, I did not realize it initially).

[ncalexan]

This doesn't seem to happen with all targets. In particular, x86_64-apple-darwin seems unaffected, while i686-linux-android is effected (really all android targets seem to be affected).

For more context: the Android toolchains are all specifying a stand-alone Android NDK toolchain, in particular a clang-based toolchain. I believe our Desktop targets (like x86_64-apple-darwin) are GCC based. So we may just be seeing a clang-ism as it passes linking through to an Android NDK toolchain GNU ld. I haven't tried lld to get to the bottom of this.

[Mark-Simulacrum]

The right fix here might be that the relevant extern blocks should get kind = "static" on the link attributes, per #62088 (comment).

[thomcc]

@Mark-Simulacrum This issue is about no_mangle symbols from another crate that get brought in by use. There are no extern blocks.

[kvark]

Heads up - this hits us in https://github.com/gfx-rs/wgpu as well. Very annoying and inconvenient, would very much appreciate any progress here!

[hansihe]

Hitting this issue as well.

My use-case is exporting some functions from my executable, then loading a dynamic library that needs to link to those symbols.