-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Latest changes in nightly cause it to produce executable named "-pie" in the crate directory. #48884
Comments
Seems like #48076 is likely to be related? @canarysnort01 |
That's my suspicion @sfackler |
hmm my change shouldn't have impacted when the -pie flag was sent, only added the -no-pie flag. what version were you using before? |
Could you please build with |
triage: P-high Not assigning this to anyone immediately, since @canarysnort01 seems to be on it -- @berkus, if you could take a shot at supplying that debug output it would be very helpful, thanks. =) |
|
@canarysnort01 does that contain the info you needed? |
It does look weird as I don't see any standalone |
Yes, that helps. I think this is what is happening:
@berkus Can you confirm this by manually running:
(same command line without -no-pie) to see if it works correctly, and also a I need to look more into ld to see if -no-pie is even necessary for it, I think maybe the default pie stuff might only be applicable with the gcc front-end. If so, I think the fix would be to change the code not to generate -no-pie if linking with ld. |
nm, I think I was able to reproduce this. I don't see -no-pie documented for ld so I think that is the problem. I'll work on a fix. |
don't pass -no-pie to gnu ld fixes rust-lang#48884
Thanks, I will test this asap! |
Works! Thank you! |
Updated to
rustc 1.26.0-nightly (2789b067d 2018-03-06)
via rustup.I have a custom target file and additional cargo configs which specify additional rustc arguments.
Now if I run
The build will succeed but then fail to run qemu because
Instead, there's a file named
-pie
in the directory where xargo was run from.To fix this I had to change the target json file with these options:
I'm afraid this could subtly break my builds elsewhere, as the linker is, in fact, GNU ld.
I believe this is related to the latest -pie/-no-pie patches which somehow interfere with custom cargo linker arguments specifications (where
-pie
ends up landing instead of output file name).The text was updated successfully, but these errors were encountered: