Repository navigation
Compiling to Shared Library doesn't always expose reexported symbols #50007
Description
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.
Reacted by Thom Chiovoloni, XeroOl, Dzmitry Malyshau, Holden Green, Hugo van der Wijst, Danilo Bargen, Diana, KC, Dylan Ede, Hans Elias J. and 6 more
Activity
dbrgn commentedon May 15, 2018
Maybe a duplicate of #36342?
thomcc commentedon Nov 8, 2018
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-darwinseems unaffected, whilei686-linux-androidis 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 commentedon Nov 8, 2018
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 aclang-ism as it passes linking through to an Android NDK toolchain GNUld. I haven't triedlldto get to the bottom of this.Mark-Simulacrum commentedon Aug 10, 2019
The right fix here might be that the relevant extern blocks should get
kind = "static"on the link attributes, per #62088 (comment).thomcc commentedon Aug 10, 2019
@Mark-Simulacrum This issue is about no_mangle symbols from another crate that get brought in by
use. There are noexternblocks.kvark commentedon Feb 12, 2020
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 commentedon May 14, 2020
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.
Move record::c_api back in the main record module.
Move record::c_api back in the main record module.
Rust: Force symbol re-export from libglean_ffi.
Rust: Force symbol re-export from libglean_ffi.
Rust: Force symbol re-export from libglean_ffi.
18 remaining items
Rollup merge of rust-lang#95604 - nbdd0121:used2, r=petrochenkov
Rollup merge of rust-lang#95604 - nbdd0121:used2, r=petrochenkov
Disable thin lto for dev builds by default in template
Disable thin lto for dev builds by default in template
Disable thin lto for dev builds by default in template
Disable thin lto for dev builds by default in template (#1035)
Disable thin lto for dev builds by default in template (pgcentralfoun…