-
Notifications
You must be signed in to change notification settings - Fork 13.4k
rust_extern_with_linkage___dso_handle+0x0): undefined reference to `__dso_handle' #140955
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
Comments
The list of dependencies for the project are:
|
You didn't provide crt objects to the linker. When calling linker directly you have to take care of it. |
I didn’t on the version that compiled. Same exact build command, same dependencies installed. Builds on 1.74, fails on 1.81. What would be the proper library to include on the linker for version 1.81? |
@tkennedy1-godaddy would you like to run cargo bisect-rustc to narrow down the rustc commit range that intoduced this change in behavior? (I don't know much about CRT myself, but bisected PR description is often insightful in these cases, in my experience) @rustbot label: +A-linkage +A-cross |
@moxian yes i can get to that this afternoon pdt |
|
Amazingly this build system was finalized in Feb 2024, so it looks like I really dodged a bullet there :) |
I think something else must have pulled the necessary objects.
Just as with C. |
The
These paths are passed in via the And more importantly, if I leave them out, the linker is unable to link to gcc_s, which is is one of the libraries located in those paths. Here's the error if I omit those
And here's the library it's looking for.
The fact that we're referring to
And has been an issue in the past, specifically in Rust makes me think something else might be going on here other than "it wasn't supported and now it's not supported at all". It might be a "it wasn't supposed to be supported and so it was an accident that it was supported" type thing, but given that even providing the correct libraries still causes this to break and the information in that gist, I'm not thoroughly convinced. |
The linker doesn't link all everything it can find inside directories provided with
Yep, that's a library linked by
I cannot give meaningful insight on that part, but maybe some Rust's ELF expert can help. |
@mati865 no, the
I did, however, try that, both with a wildcard to let shell-globbing fill it in, and once with all the crt libraries provided, to the same exact result as above -- the |
(and yes, I also tried prefixing them with |
@tkennedy1-godaddy no, The help that you quoted confirms that: |
The problem is that I am filing this bug because the rust compiler is supposed to handle this for you specifically as well. Given that it worked in the past, and no longer works without a specific reference in the changesets makes me strongly feel this is a regression and not something that is "working as intended." Passing in |
When compiling for any Unix target, you should avoid directly invoking the linker. Rather you should use gcc or clang as linker driver. They will handle passing the linker search path, any extra libraries and object files that need to be linked, set the dynamic linker, any exploit mitigations and whatever other flags are necessary to link. Also even gcc and clang don't directly invoke the linker on many systems, rather they invoke collect2 which is another wrapper around the linker that is on some systems necessary to get global constructors working. For example compiling on my debian system gcc will run the following:
If you are cross-compiling you should use the gcc or clang that is part of the cross-compilation toolchain as |
I'm not invoking the linker directly, rather telling (via the
(It also doesn't matter if I use |
This is basically invoking the static linker directly from rustc, rather than going through the supported way of letting GCC+collect2 or Clang invoke the linker. |
How would you recommend I explain to the compiler that it needs to invoke a specific linker for this platform? There are several ways to tell cargo what to do, but even if I do this:
I still get the same error with the If I remove all the overrides for the compiler/linker I'm left with the obnoxious linker issue of
Even if I use the not-documented-as-far-as-I-can-tell HOWEVER. Through tons of "reading posts" I happened across someone using
So @mati865 I do need to provide the linker via the |
The right linker to pass as argument to |
Like I and bjorn3 already said, the right way to link is by calling
This is expected because you still call
That means your
rustc doesn't pass
because static linkers don't support this argument. But to link via static linker you have to manually pass correct runtime objects in correct order, which you didn't do. Hence, the __dso_handle error.
No,
This is definitely not a supported way to use You can verify used linker with |
@mati865 at no time in this thread did you suggest that I should do that, except possibly in #140955 (comment). @bjorn3 I appreciate the straight forward advice. This feels like all of this information should be properly documented somewhere. I'm happy to do that -- is there a recommendation for where this should all go? Most of this stuff was cobbled together from blog posts or threads on the rust discussions where most of these solutions are proffered as the correct way to go about this. |
@tkennedy1-godaddy I assumed it was a deliberate decision to avoid calling GCC or Clang, so I focused on the last thing you were missing and also missed the fact you were not using x86_64 host (which would be more obvious from
I just looked it up, and indeed, the official documentation is basically absent (or not found by Google and Brave Search). I think there used to be something, but maybe the memory fails me. Definitely something worth acting on. Also, it could be helpful if more targets included FWIW the best way to configure linker when cross-compiling is via |
I improved the docs for |
I tried this code:
Trying to cross compile (from aarch64 to x86_86 on linux)
I expected to see this happen: explanation
The software compiled correctly.
Instead, this happened: explanation
The linker failed on trying to link Rust's libstd.
Meta
rustc --version --verbose
:Backtrace
This does work correctly on rust 1.74.0 on the same system. I have been unable to test other versions yet, nor create a self-contained example.
The build command for this is:
The text was updated successfully, but these errors were encountered: