Error explanation suggests using #![no_std] when already in use

[klieth]

I've been running into a linker error undefined reference to 'panicking::panic::h98aad983367da335F7E' while trying to build with #![no_std]. While trying to debug, I ended up with some code that looked like this:

https://gist.github.com/anonymous/88c01ee6ee33e4bad656

When you try to compile, it fails saying that "panic" is a duplicate definition. This makes sense because it's defined in libcore, but the error explanation suggests that this is possible, and the correct way to to do it is to use #![no_std], which I'm already doing.

Seems like either a problem with the library or with the error explanation?

[abusse]

Is there any news on this issue? I'm trying to build a bare metal application and run exactly into this issue.

[steveklabnik]

@abusse I haven't heard of anyone else mention it.

For reference, @klieth 's example today gives me:

<anon>:11:1: 14:2 error: duplicate lang item found: `panic`. [E0152]
<anon>:11 extern fn panic(expr_file_line: &(&'static str, &'static str, u32)) -> ! {
<anon>:12     let (expr, file, line) = *expr_file_line;
<anon>:13     panic_fmt(fmt::Arguments::new_v1(&[expr], &[]), &(file, line))
<anon>:14 }
<anon>:11:1: 14:2 help: see the detailed explanation for E0152
note: first defined in crate `core`.
error: aborting due to previous error
playpen: application terminated with error code 101

No suggestion of no_std. @abusse , what is your code?

[abusse]

Thank you @steveklabnik for the very fast answer and shame on me for not replying for such a long time, but I got stuck with a very urgent project the next day until recently.

My issue does not regard the error message, but the error itself. I get the same result as you when compiling @klieth 's example. However, when I do not define the panic function I get stuck at the linking error as @klieth described. So my issue is, how do I get my final binary when I a) cannot define a panic function while b) the linker expects it to be there?

[steveklabnik]

Okay, so, I don't think this is a bug, then. You have to define these lang items; https://doc.rust-lang.org/stable/book/no-stdlib.html has some examples, though they are out of date. #33677 has been open for this; I'm just going to do it right now.

I would encourage you, if you're still having trouble, to open a thread on users.rust-lang.org about this, with the exact code and what you're doing. Thanks!

[abusse]

Again, thank you for the fast answer. Are you absolutely sure it is not a bug? Even though, I am trying to define these language items the compiler/language is simply not allowing me to define panic. It works perfectly fine for eh_personality and panic_fmt as you described in the document above, but the compiler simply refuses to accept my definition for panic as duplicated. However, as I use [no_std] the linker in the end (no surprise) does not find the panic function. I have no issues with the language items explained in the documentation that part works perfectly fine.

I'm pretty new to Rust, so I will trust you when you say you are absolutely sure that it is the intended behaviour of the compiler to reject my definition of panic as a duplicate. I just want to make sure you are.

[steveklabnik]

Yes, you should not be defining a "panic function." panic isn't even a function in Rust; it's a macro. The exact code would be extremely helpful here.

[abusse]

Sorry that I can give you the minimal example just now, it took me some time to strip down the code and still maintain the problem as the original code contains a lot of complicated wrapping to C code. Take this gist as example:
https://gist.github.com/abusse/ad35d7d6a36002f8cb521ab862efd4b5
When I compile it with rustc -g --emit obj and do an object dump I get the following:
https://gist.github.com/abusse/94c034d97157a153e78d237f59b06b25

As you can see in line 19 there is a symbol _ZN4core9panicking5panic17h9fc32ab32290f408E. When I try to link this object against rest of my code this symbol cannot be resolved.

Furthermore, there is another similar issue that is most likely the same or at least related, but I was not able to maintain it in the simple example. In my complete more complicated code I also have a symbol after compiling called _ZN4core9panicking18panic_bounds_check17h1e38a0a317edd68fE, which causes the same problem in the end.

[steveklabnik]

Please open a thread on users for this.

[abusse]

I think I figured out what the issue is. Just for the record in case someone else comes about this issue: I assumed that [no_std] already gives me a bare-metal setup, but apparently also [no_core] is needed as well otherwise the core library has to be linked against the final binary. Thanks again for the quick support, it's really good to see that people are so dedicated to this project!