Skip to content

/rust

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

Link error regression on nightly #36155

Closed
alexcrichton opened this Issue Aug 31, 2016 · 13 comments

Comments

Assignees

@michaelwoerister michaelwoerister

Labels
A-linkage P-high T-compiler regression-from-stable-to-nightly
Projects
None yet
Milestone
No milestone
7 participants
@alexcrichton @nikomatsakis @michaelwoerister @TimNN @eddyb @vinipsmaker @rust-highfive
@alexcrichton
Copy link
Member

alexcrichton commented Aug 31, 2016

When running cargo test inside the futures-cpupool folder of rust-lang-nursery/futures-rs@093a638, I get an error looking like:

$ cargo +nightly test
   Compiling crossbeam v0.2.10
   Compiling libc v0.2.15
   Compiling log v0.3.6
   Compiling futures v0.1.0 (file:///home/alex/code/futures)
   Compiling num_cpus v1.0.0
   Compiling futures-cpupool v0.1.0 (file:///home/alex/code/futures/futures-cpupool)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/alex/code/futures/futures-cpupool/target/debug/smoke-d9fe7840395d70dc.0.o" "-o" "/home/alex/code/futures/futures-cpupool/target/debug/smoke-d9fe7840395d70dc" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/alex/code/futures/futures-cpupool/target/debug/deps" "-L" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-411f48d3.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/libfutures_cpupool.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/libnum_cpus-f32c6a9cbd8fad0a.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/libcrossbeam-2f53cae32cd2c9f1.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/libfutures.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/liblog-bf16bb9a4912b11d.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-411f48d3.rlib" "/home/alex/code/futures/futures-cpupool/target/debug/deps/liblibc-1bd8847afb79f283.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-411f48d3.rlib" "/home/alex/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-411f48d3.rlib" "-l" "util" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
  = note: /home/alex/code/futures/futures-cpupool/target/debug/smoke-d9fe7840395d70dc.0.o: In function `futures_cpupool::{{impl}}::spawn<futures::lazy::Lazy<closure, core::result::Result<(), ()>>>':
/home/alex/code/futures/futures-cpupool/src/lib.rs:165: undefined reference to `_$LT$futures..task..Spawn$LT$Box$LT$futures..Future$LT$Error$u3d$$LP$$RP$$C$$u20$Item$u3d$$LP$$RP$$GT$$u20$$u2b$$u20$Send$u20$$u2b$$u20$$u27$static$GT$$GT$$GT$::execute::he6071928c27d1a12'
/home/alex/code/futures/futures-cpupool/target/debug/smoke-d9fe7840395d70dc.0.o: In function `futures_cpupool::{{impl}}::spawn<Box<Future>>':
/home/alex/code/futures/futures-cpupool/src/lib.rs:165: undefined reference to `_$LT$futures..task..Spawn$LT$Box$LT$futures..Future$LT$Error$u3d$$LP$$RP$$C$$u20$Item$u3d$$LP$$RP$$GT$$u20$$u2b$$u20$Send$u20$$u2b$$u20$$u27$static$GT$$GT$$GT$::execute::he6071928c27d1a12'
collect2: error: ld returned 1 exit status
$ rustc +nightly -vV
rustc 1.13.0-nightly (77d2cd28f 2016-08-29)
binary: rustc
commit-hash: 77d2cd28fd715d2b9751de82b14d28ce6e376728
commit-date: 2016-08-29
host: x86_64-unknown-linux-gnu
release: 1.13.0-nightly

I haven't had a chance to minimize this yet unfortunately, but I figure that a bug report is better than no bug report.

@alexcrichton alexcrichton added A-linkage I-nominated regression-from-stable-to-nightly T-compiler labels Aug 31, 2016

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Aug 31, 2016

Appears to be related to this:

impl Spawn<BoxFuture<(), ()>> {
    pub fn execute(self, exec: Arc<Executor>) {
        // ...
    }
}

That's one of the undefined functions. If I change that instead to impl<F: Future> Spawn<F> { ... } then everything links up correctly.
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Sep 1, 2016

cc @michaelwoerister -- could this be related to collector changes?

@nikomatsakis nikomatsakis assigned michaelwoerister Sep 1, 2016

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Sep 1, 2016

triage: P-high -- this is a regression.

Going to assign to @michaelwoerister for now on the suspicion that it is related to the collector.

@rust-highfive rust-highfive added P-high and removed I-nominated labels Sep 1, 2016

@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 1, 2016

This might have to do with the switch to MIR trans since on-demand monomorphization for functions went away with that. That might have exposed a preexisting hole in the collector.

@TimNN TimNN referenced this issue Sep 7, 2016

Closed

rustc 1.13.0-nightly exit with linkage error, when compiling 'Rust by Example - 8.2.5 As output parameters' code. #36260

@TimNN

This comment has been minimized.

Sign in to view
Copy link
Contributor

TimNN commented Sep 7, 2016 •
edited

nightly-2016-08-22 is still fine, nightly-2016-08-23 fails; changes.
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 12, 2016

@TimNN Thanks for looking into this!
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 12, 2016

The problem seems to be that the symbol is not exported from the upstream crate anymore. Making the impl generic, as @alexcrichton did, will give the compiler the chance to instantiate a new copy of the method in the current crate and thus side-steps the problem.
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 12, 2016

Oh, yuck, the symbol is still exported, but the upstream and the downstream crate don't compute the same name b/c impl names are indeterministic, it seems:

_$LT$futures..task..Spawn$LT$Box$LT$futures..Future$LT$Item$u3d$$LP$$RP$$C$$u20$Error$u3d$$LP$$RP$$GT$$u20$$u2b$$u20$Send$u20$$u2b$$u20$$u27$static$GT$$GT$$GT$::execute::he2c53ed21be0e6cc
                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_$LT$futures..task..Spawn$LT$Box$LT$futures..Future$LT$Error$u3d$$LP$$RP$$C$$u20$Item$u3d$$LP$$RP$$GT$$u20$$u2b$$u20$Send$u20$$u2b$$u20$$u27$static$GT$$GT$$GT$::execute::he2c53ed21be0e6cc
                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Sep 12, 2016 •
edited

@michaelwoerister May be a good idea to never take this branch if the buffer is in absolute mode.

EDIT: The symbols are hard to read, apparently those are actually associated types, nevermind.

@michaelwoerister michaelwoerister referenced this issue Sep 12, 2016

Merged

Fix indeterminism in ty::TraitObject representation. #36425

@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 12, 2016

@eddyb Maybe. Though in the long run, we should just not use item_path for anything in symbol names, I guess.
@vinipsmaker

This comment has been minimized.

Sign in to view
Copy link

vinipsmaker commented Sep 12, 2016

nightly-2016-08-22 is still fine, nightly-2016-08-23 fails; changes.

rustup is failing to download nightly-2016-08-23 in my machine, but I've tried 2016-08-24 and it fails.

Yes, mine is a different project and fails because:

crust.cgu-0.rs:(.text._ZN4drop17h3e1234ed18e9763aE+0xd): undefined reference to `_$LT$alloc..rc..Weak$LT$T$GT$$u20$as$u20$core..ops..Drop$GT$::drop::heb9833ada23bd943'
/home/ubuntu/Projetos/crust/target/debug/deps/crust-c77ec8e2f8c19198.0.o: In function `drop::hd8b7fe7b4a4d2a8d':
crust.cgu-0.rs:(.text._ZN4drop17hd8b7fe7b4a4d2a8dE+0xd): undefined reference to `_$LT$alloc..rc..Weak$LT$T$GT$$u20$as$u20$core..ops..Drop$GT$::drop::hc1ce591e95fae7c5'
collect2: error: ld returned 1 exit status

The full log for a different build which failed for the same reason is available online: https://travis-ci.org/maidsafe/crust/jobs/159284568#L294

Is there anything I can do to help chase this error?

@vinipsmaker vinipsmaker referenced this issue Sep 12, 2016

Closed

Link failure with Rust nightly #800

@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Sep 12, 2016

@vinipsmaker That looks more like #36260, which I'm going to look into next.

bors added a commit that referenced this issue Sep 14, 2016

@bors
Auto merge of #36425 - michaelwoerister:stable-projection-bounds, r=e… 
…ddyb

Fix indeterminism in ty::TraitObject representation.

Make sure that projection bounds in `ty::TraitObject` are sorted in a way that is stable across compilation sessions and crate boundaries.

This PR
+  moves `DefPathHashes` up into `librustc` so it can be used there to create a stable sort key for `DefId`s,
+ changes `PolyExistentialProjection::sort_key()` to take advantage of the above,
+ and removes the unused `PolyProjectionPredicate::sort_key()` and `ProjectionTy::sort_key()` methods.

Fixes #36155
fdb4f63

Manishearth added a commit to Manishearth/rust that referenced this issue Sep 15, 2016

@Manishearth
Rollup merge of rust-lang#36425 - michaelwoerister:stable-projection-… 
…bounds, r=eddyb

Fix indeterminism in ty::TraitObject representation.

Make sure that projection bounds in `ty::TraitObject` are sorted in a way that is stable across compilation sessions and crate boundaries.

This PR
+  moves `DefPathHashes` up into `librustc` so it can be used there to create a stable sort key for `DefId`s,
+ changes `PolyExistentialProjection::sort_key()` to take advantage of the above,
+ and removes the unused `PolyProjectionPredicate::sort_key()` and `ProjectionTy::sort_key()` methods.

Fixes rust-lang#36155
7494bc7

@bors bors closed this in #36425 Sep 15, 2016

@vinipsmaker

This comment has been minimized.

Sign in to view
Copy link

vinipsmaker commented Sep 19, 2016

Just tested with rustc 1.13.0-nightly (32571c05c 2016-09-17) and it worked where previously failed.

TethysSvensson pushed a commit to TethysSvensson/futures-rs that referenced this issue Jan 12, 2017

Mathias Svensson
Restrict the Spawn::execute function 
Since rust-lang/rust#36155 has been fixed, we can avoid an extra box
allocation when calling Spawn::execute with an already boxed future.

The downside of this is that it is compatibility breaking. I am now sure
if it is worth the breakage to get the performance improvement in a few
cases.
d0f2fb3

TethysSvensson pushed a commit to TethysSvensson/futures-rs that referenced this issue Jan 12, 2017

Mathias Svensson
Restrict the Spawn::execute function 
Since rust-lang/rust#36155 has been fixed, we can avoid an extra box
allocation when calling Spawn::execute with an already boxed future.

The downside of this is that it is compatibility breaking. I am now sure
if it is worth the breakage to get the performance improvement in a few
cases.
e55fee9

@TethysSvensson TethysSvensson referenced this issue Jan 12, 2017

Closed

Restrict the Spawn::execute function #351

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.