Skip to content

Link error when compiling reqwest with -C prefer-dynamic #82972

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

Closed
davidlattimore opened this issue Mar 10, 2021 · 1 comment · Fixed by #113695
Closed

Link error when compiling reqwest with -C prefer-dynamic #82972

davidlattimore opened this issue Mar 10, 2021 · 1 comment · Fixed by #113695
Labels
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.

Comments

@davidlattimore
Copy link
Contributor

I gather that prefer-dynamic isn't the preferred mode of compiling, but I use it in Evcxr to try and keep memory usage down when compiling and loading lots of .so files with similar dependencies.

Cargo.toml:

[package]
name = "foo"
version = "1.0.0"
edition = "2018"

[dependencies]
reqwest = "0.11"
tokio = {version = "1.2.0", features = ["full"]}

main.rs:

fn main() {
    let _ = tokio::runtime::Runtime::new()
        .unwrap()
        .block_on(async { reqwest::get("https://www.rust-lang.org") });
}

cargo build succeeds, however cargo rustc -- -C prefer-dynamic fails to link with lots of missing symbols. e.g.:

/usr/bin/ld: /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-channel-0.3.13/src/oneshot.rs:224: undefined reference to `core::mem::drop'
/usr/bin/ld: /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-channel-0.3.13/src/oneshot.rs:233: undefined reference to `core::ptr::drop_in_place<futures_channel::lock::TryLock<core::option::Option<core::task::wake::Waker>>>'

Meta

Got this behavior on nightly 2021-03-09 as well as stable versions back as far as 1.44. Prior that the code doesn't compile due to missing features.

rustc +nightly --version --verbose:

rustc 1.52.0-nightly (3a5d45f 2021-03-09)
binary: rustc
commit-hash: 3a5d45f
commit-date: 2021-03-09
host: x86_64-unknown-linux-gnu
release: 1.52.0-nightly
LLVM version: 12.0.0

Original report: evcxr/evcxr#156

@davidlattimore davidlattimore added the C-bug Category: This is a bug. label Mar 10, 2021
@bjorn3 bjorn3 added A-linkage Area: linking into static, shared libraries and binaries T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 10, 2021
@BGR360
Copy link
Contributor

BGR360 commented Jan 25, 2022

See also #82151 (comment)

@bors bors closed this as completed in b14fd23 Jul 20, 2023
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Jul 22, 2023
…nkfelix,petrochenkov

Verify that all crate sources are in sync

This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib.

Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.

Fixes rust-lang/rust#10786
Fixes rust-lang/rust#82151
Fixes rust-lang/rust#82972
Closes bevy-cheatbook/bevy-cheatbook#114
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants