Linker error when building my rust application #138
Comments
|
If I recall correctly (but I might be wrong, it's been a while since I hacked on this) this assertion is triggered by Rust passing It can happen that |
|
This is the full command which causes the assertion failure: I've not used |
|
I re-arranged my source code and now the error is changed to this: |
|
Exactly the same application on different toolchain versions (gcc5.4 and binutils 2.26.1) produce the following error: |
|
That's interesting. Could indicate that the assertions were also triggered by these conflicts. I'm wondering though how the conflicts can occur in the first place. |
|
If I'm guessing correctly, the conflicts are probably occurring because:
Fixing "2" is anything but easy (at least AFAIK), but fixing "1" alone might do the trick. I'm all for someone fixing "2" ;-) |
|
Good point. The Rust standard library (as well as their libc bindings) have long been patched not to explicitly request I fully agree that fixing "2" would be the right thing to do :) If I manage to allocate some free time, I might take a stab at it (or at least get a better understanding of the issue), but no promises! In the mean time, it seems to me the workaround is to avoid passing @javadebrahimian Do you see if any of the crates your project use something like Currently unclear to me is if libc is a special case here, of if this can happen with any library. If libc is a special case, perhaps we could hack around this in app-tools (as a workaround), and manually strip any superfluous |
|
I looked at all of the crates in my cargo registry and non of them explicitly use |
|
A new observation: But this one produces linker assertion failure as mentioned before: And this one builds and works: Seems weird to me. I'm not sure what's happening, but I have one hypothesis: the second test function ( To be more specific, the line As I said I'm not sure about it, so please let me know if you have any ideas about it. |
|
Thanks for the update, I might take a closer look later this week. I just wanted to post a heads up that Rumprun does not support dynamic linking, so any crate that depends on libloading will most likely be broken. :/ |
|
I can confirm that the error came from using the libloading crate. By replacing the used functions with my own ones, the linker does not fail anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have the following linker error when I want to build my rust application (which works on Linux and MacOS) on rumprun-hw:
I've seen the same error (all pointing to elflink.c, but different lines) on both Ubuntu 14.04 and 16.04, using GCC4.8, 4.8, 5.4 and 6, and binutils 2.24, 2.25, 2.26.1 and 2.28.
Just binutils 2.28 points to a relevant line in elflink.c with an assersion in it.
This is the assertion which fails on 2.26.1:bfd/elflink.c:8300 and 2.28:bfd/elflink.c:8462:
The text was updated successfully, but these errors were encountered: