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

src/liballoc/alloc.rs:169: undefined reference to `<core::ptr::Unique<T>>::as_ptr' #52528

Closed
oli-obk opened this issue Jul 19, 2018 · 6 comments
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

@oli-obk
Copy link
Contributor

oli-obk commented Jul 19, 2018

Tests with panic=abort cause

In function `alloc::alloc::box_free':
          /home/oliver/Projects/rust/rust3/src/liballoc/alloc.rs:169: undefined reference to `<core::ptr::Unique<T>>::as_ptr'
          /home/oliver/Projects/rust/rust3/src/liballoc/alloc.rs:169: undefined reference to `<core::ptr::Unique<T>>::as_ptr'
          /home/oliver/Projects/rust/rust3/src/liballoc/alloc.rs:169: undefined reference to `<core::ptr::Unique<T>>::as_ptr'
          collect2: error: ld returned 1 exit status

For me locally.

This isn't happening on Travis.

Maybe it's

  • debuginfo,
  • fullmir
  • incremental

related? Because I have all of these set in my config.toml. Has been happening since I rebased yesterday.

I'll investigate locally.

@oli-obk oli-obk added A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. labels Jul 19, 2018
@varkor
Copy link
Member

varkor commented Aug 4, 2018

I get similar errors for these three tests:

run-pass/panic-runtime/abort-link-to-unwinding-crates.rs
run-pass/panic-runtime/abort.rs
run-pass/panic-runtime/link-to-abort.rs

with this error:

= note: ld: warning: directory not found for option '-L~/GitHub/rust/build/x86_64-apple-darwin/test/run-pass/panic-runtime/abort/auxiliary'
          Undefined symbols for architecture x86_64:
            "_$LT$core..ptr..Unique$LT$T$GT$$GT$::as_ptr::h40c70ffcb9fa71ff", referenced from:
                core::ptr::drop_in_place::h13ea34cb88507684 in libstd-1b5266ff4a5237d6.rlib(std-1b5266ff4a5237d6.2ujrhqd1it5k4nvl.rcgu.o)
                alloc::alloc::box_free::hf8887d7620bb9fc3 in libstd-1b5266ff4a5237d6.rlib(std-1b5266ff4a5237d6.2ujrhqd1it5k4nvl.rcgu.o)
                std::rt::lang_start_internal::h298a301fc3e8b601 in libstd-1b5266ff4a5237d6.rlib(std-1b5266ff4a5237d6.2ujrhqd1it5k4nvl.rcgu.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

@pnkfelix
Copy link
Member

pnkfelix commented Sep 14, 2018

One thing I just realized: some of our bugs seem very sensitive to whether you are running under optimize or not (i.e. are you compiling the tests with -O).

See for example #54153

I often have optimize-tests set to false in my config.toml for my local rustc builds without even thinking about it (literally, due to an artifact of how I clone my repo locally), but the default for the setting is true.

(I also don't know what setting I am using that is exposing the problems that I see that are similar to that listed by @varkor above, but I currently hypothesize that I am seeing it in the context of a build with optimize-tests set to false.)

What about you two, @oli-obk and @varkor ? Do you override that setting typically/often? Or do you usually leave it at its default of false?

(I ask mainly because I am continuously wondering why other people, and our continuous-integration server, do not run into these issues...)

@varkor
Copy link
Member

varkor commented Sep 14, 2018

I think I've only ever tried testing these with the default optimisation mode.

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 14, 2018

I don't think I have set tests to run without optimizations

@pnkfelix pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 20, 2018
@steveklabnik
Copy link
Member

@oli-obk are you still seeing this?

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 10, 2019

I haven't seen this in a long time. Not sure what changed.

@oli-obk oli-obk closed this as completed Dec 10, 2019
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

No branches or pull requests

4 participants