Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"undefined symbol" when loading dylib compiled on >1.36.0 #67070

Open
GinjaNinja32 opened this issue Dec 5, 2019 · 4 comments
Open

"undefined symbol" when loading dylib compiled on >1.36.0 #67070

GinjaNinja32 opened this issue Dec 5, 2019 · 4 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. E-needs-test Call for participation: Writing correctness tests. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@GinjaNinja32
Copy link

undefined symbol: _ZN42_$LT$$RF$T$u20$as$u20$core..fmt..Debug$GT$3fmt17hd0ba07f053fd4c7fE

My project structure:

parent
    main.rs  # binary, loads libchild.so via libloading
    lib.rs   # dylib, shared code
child
    lib.rs   # dylib, dynamically linked to libparent.so

This compiles fine, but fails to load libchild.so when compiled on anything newer than 1.36.0. If the parent library is made non-dylib, it works fine, however this is not a viable solution for my project as it causes libchild.so to contain all the shared code, and my project has many libchild.so-equivalent crates.

Demo case: https://github.com/GinjaNinja32/rust-issues/tree/undefined-symbol-core-fmt-debug (has 70 dependency crates, mostly indirect; I'm not sure exactly where it goes wrong or how to make it smaller)

Bisected to merge dbebcee, #59752.

rustc 1.39.0 (4560ea788 2019-11-04)
binary: rustc
commit-hash: 4560ea788cb760f0a34127156c78e2552949f734
commit-date: 2019-11-04
host: x86_64-unknown-linux-gnu
release: 1.39.0
LLVM version: 9.0
@GinjaNinja32
Copy link
Author

...and now my test project does the same thing on 1.36.0.

My real project works fine on 1.36.0, so maybe my test project just has a different bug that happens to give the same error? I have no idea what's going on with this.

The bisection results were with my real project, though, so those should be accurate for the issue I'm actually seeing there.

@jonas-schievink
Copy link
Contributor

Caused by #59752

@nagisa
Copy link
Member

nagisa commented Dec 8, 2019

Possible duplicate of #65610. The linked issue as the fix you can make to the code to make this work again (you need the #[link] annotations on your extern blocks) My bad, this project does not involve extern blocks.

@Alexendoo Alexendoo added A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 15, 2020
@GinjaNinja32
Copy link
Author

Rust 1.42 seems to fix this for my real project; the test project I linked above remains broken even on nightly 2020-02-19.

My real project now doesn't even build on 1.37-1.41 (see #69328), but it builds and runs fine on both 1.36 and 1.42.

@bjorn3 bjorn3 added the E-needs-test Call for participation: Writing correctness tests. label Jul 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. E-needs-test Call for participation: Writing correctness tests. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants