-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement flexible target specification #16156
Conversation
Still trying to figure out a bug where executables aren't getting the executable bit set... |
Seems to have resolved itself with a rebase ¯_(ツ)_/¯ |
let mut paths = os::split_paths(target_path.as_slice()); | ||
// FIXME: should be relative to the prefix rustc is installed in, and do something | ||
// different for Windows. | ||
paths.push(Path::new("/etc/rustc")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who installs to /etc/rustc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature may want to remain unimplemented for now due to some open questions here, but it probably doesn't matter too much.
Can you write a run-make test that checks the compiler is correctly searching for, parsing and using external specifications? (E.g. it could run |
Another issue: probably needs to allow specifying |
(The RFC specifies taking it from the target) |
@huonw how do those docs look? |
Hm, glaringly obvious problem: |
@farcaller we should try this with |
Be warned that this isn't quite working yet. My current status is:
|
(Already fixed I think, still building..) |
//! will be given. `RUST_TARGET_PATH` includes `/etc/rustc` as its last entry, to be searched by | ||
//! default. | ||
//! | ||
//! Projects defining their own targets should use `--target=path/to/my-awesome-platform.json` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a story for interacting with cargo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not yet, no.
When compiling this on DragonFly I run into these problems:
Maybe the |
|
||
pub fn target() -> Target { | ||
Target { | ||
function_sections: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
false => true ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nevermind, it would be nice to preserve the comments in the source code to this target specification about why this is false
If someone else wants to take over this PR I wouldn't be offended, I know this feature is sorely needed. |
"-Wl,--enable-long-section-names".to_string(), | ||
// Mark all dynamic libraries and executables as compatible with the larger 4GiB | ||
// address space available to x86 Windows binaries on x86_64. | ||
"-Wl,--large-address-aware".to_string(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like x86_64 linker doesn't understand this option, but i686 does.
Rebased, fixed, squashed: https://github.com/vadimcn/rust/tree/flextarget. Passes tests on Windows. |
Revived, yay! |
@@ -1100,12 +1123,15 @@ do | |||
|
|||
if [ ${do_reconfigure} -ne 0 ] | |||
then | |||
msg "configuring LLVM for $t" | |||
# LLVM's configure doesn't recognize the new Windows triples yet | |||
$gnu_t=$(to_gnu_triple $t) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- $gnu_t=$(to_gnu_triple $t)
+ gnu_t=$(to_gnu_triple $t)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, @klutzy is absolutely right! I guess this doesn't break stuff unless LLVM needs to be rebuilt...
Darn it! What's going on here??? |
I can't replicate the android failure locally. @alexcrichton do you know what API level the emulators are using? |
Looks like #17448, but I think that we're using api version 19 maybe? |
Removes all target-specific knowledge from rustc. Some targets have changed during this, but none of these should be very visible outside of cross-compilation. The changes make our targets more consistent. iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We used to accept any value of X greater than 1. i686 was released in 1995, and should encompass the bare minimum of what Rust supports on x86 CPUs. The only two windows targets are now i686-pc-windows-gnu and x86_64-pc-windows-gnu. The iOS target has been renamed from arm-apple-ios to arm-apple-darwin. A complete list of the targets we accept now: arm-apple-darwin arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf i686-apple-darwin i686-pc-windows-gnu i686-unknown-freebsd i686-unknown-linux-gnu mips-unknown-linux-gnu mipsel-unknown-linux-gnu x86_64-apple-darwin x86_64-unknown-freebsd x86_64-unknown-linux-gnu x86_64-pc-windows-gnu Closes #16093 [breaking-change]
@cmr Congrats! :-) |
See commit message.