Implement flexible target specification #16156

emberian · 2014-08-01T02:58:35Z

See commit message.

emberian · 2014-08-01T02:59:11Z

Still trying to figure out a bug where executables aren't getting the executable bit set...

emberian · 2014-08-01T07:25:43Z

Seems to have resolved itself with a rebase ¯_(ツ)_/¯

huonw · 2014-08-01T07:57:35Z

src/librustc_back/target/mod.rs

Who installs to /etc/rustc?

This feature may want to remain unimplemented for now due to some open questions here, but it probably doesn't matter too much.

huonw · 2014-08-01T07:59:34Z

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 rustc --target=foo-bar-baz --emit=asm ... with a custom target that disables stack checks, and then grep for stack checks.)

emberian · 2014-08-01T08:34:07Z

Another issue: probably needs to allow specifying target_os instead of taking it from the target triple. I'm not actually sure this is a good idea, though, and it seems MUCH more clear that the target_os comes from the triple name itself. But we'd need to rename "osx" to "darwin", which I feel is almost a lie? Not really sure. Need feedback.

emberian · 2014-08-01T08:34:21Z

(The RFC specifies taking it from the target)

emberian · 2014-08-01T09:05:17Z

@huonw how do those docs look?

emberian · 2014-08-01T09:11:38Z

Hm, glaringly obvious problem: linker should probably include a target triple prefix, for cross compiling. ie, x86_64-unknown-linux-gnu-cc.

errordeveloper · 2014-08-01T09:35:58Z

@farcaller we should try this with arm-none-eabi

emberian · 2014-08-01T09:44:23Z

Be warned that this isn't quite working yet. My current status is:

LLVM ERROR: not a number, or does not fit in an unsigned int

emberian · 2014-08-01T09:47:03Z

(Already fixed I think, still building..)

huonw · 2014-08-01T09:54:54Z

src/librustc_back/target/mod.rs

Do we have a story for interacting with cargo?

Not yet, no.

mneumann · 2014-08-01T14:44:09Z

When compiling this on DragonFly I run into these problems:

/home/mneumann/rust/src/liblibc/lib.rs:2943:47: 2943:53 error: unresolved import
 `types::os::arch::c95::c_uint`. Could not find `arch` in `types::os`.
/home/mneumann/rust/src/liblibc/lib.rs:2943             use types::os::arch::c95
::{c_int, c_uint};

          ^~~~~~
/home/mneumann/rust/src/liblibc/lib.rs:2965:17: 2965:44 error: unresolved import
 `types::os::arch::c95::c_int`. Could not find `arch` in `types::os`.
/home/mneumann/rust/src/liblibc/lib.rs:2965             use types::os::arch::c95
::c_int;
                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/mneumann/rust/src/liblibc/lib.rs:2966:17: 2966:49 error: unresolved import
 `types::os::arch::posix88::mode_t`. Could not find `arch` in `types::os`.
/home/mneumann/rust/src/liblibc/lib.rs:2966             use types::os::arch::pos
ix88::mode_t;
                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/mneumann/rust/src/liblibc/lib.rs:3209:17: 3209:44 error: unresolved import
 `types::os::arch::c95::c_int`. Could not find `arch` in `types::os`.
/home/mneumann/rust/src/liblibc/lib.rs:3209             use types::os::arch::c95
::c_int;
                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/mneumann/rust/src/liblibc/lib.rs:150:54: 150:58 error: unresolved import (
maybe you meant `stat::*`?)
/home/mneumann/rust/src/liblibc/lib.rs:150 pub use funcs::posix88::stat_::{chmod
, fstat, mkdir, stat};

                ^~~~
error: aborting due to 115 previous errors
gmake: *** [x86_64-unknown-dragonfly/stage1/lib/rustlib/x86_64-unknown-dragonfly
/lib/stamp.libc] Error 101

Maybe the target_os is incorrectly determined?

alexcrichton · 2014-08-01T14:45:37Z

src/librustc_back/target/apple_base.rs

false => true ?

Ah nevermind, it would be nice to preserve the comments in the source code to this target specification about why this is false

emberian · 2014-10-29T07:02:56Z

If someone else wants to take over this PR I wouldn't be offended, I know this feature is sorely needed.

klutzy · 2014-10-29T09:07:19Z

src/librustc_back/target/windows_base.rs

Seems like x86_64 linker doesn't understand this option, but i686 does.

vadimcn · 2014-10-30T00:49:46Z

Rebased, fixed, squashed: https://github.com/vadimcn/rust/tree/flextarget. Passes tests on Windows.
@cmr: Do you want me to submit it?

aturon · 2014-10-31T20:23:15Z

Revived, yay!

klutzy · 2014-11-01T09:54:19Z

configure

- $gnu_t=$(to_gnu_triple $t) + gnu_t=$(to_gnu_triple $t)

Yup, @klutzy is absolutely right! I guess this doesn't break stuff unless LLVM needs to be rebuilt...

vadimcn · 2014-11-02T03:26:09Z

Darn it! What's going on here???

emberian · 2014-11-03T09:27:09Z

I can't replicate the android failure locally. @alexcrichton do you know what API level the emulators are using?

alexcrichton · 2014-11-03T16:30:36Z

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]

See commit message.

vadimcn · 2014-11-04T16:25:05Z

@cmr Congrats! :-)

huonw reviewed Aug 1, 2014
View reviewed changes

bvssvni mentioned this pull request Aug 1, 2014

PNaCl support for Rust PistonDevelopers/piston#514

Closed

huonw reviewed Aug 1, 2014
View reviewed changes

alexcrichton reviewed Aug 1, 2014
View reviewed changes

klutzy reviewed Oct 29, 2014
View reviewed changes

src/librustc_back/target/windows_base.rs Outdated

Copy link

Contributor

klutzy Oct 29, 2014

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.

klutzy reviewed Nov 1, 2014
View reviewed changes

emberian added 6 commits November 4, 2014 05:07

Use -m32 on 32bit Linux

0e03503

Same fix for mac32

4a6f4c9

Same fix for dragonfly

244bb14

Don't use pie on Android

70dedbb

Update some new use of the old targ_cfg

87a753e

Update for collections reform

61aeab4

bors added a commit that referenced this pull request Nov 4, 2014

auto merge of #16156 : cmr/rust/target-spec, r=alexcrichton

3a8f4ec

See commit message.

bors merged commit 61aeab4 into rust-lang:master Nov 4, 2014

ehuss mentioned this pull request Jul 20, 2019

Target specification? rust-lang/wg-cargo-std-aware#6

Open

Mark-Simulacrum mentioned this pull request Apr 10, 2020

De-stabilize target spec JSON #71009

Open

petrochenkov mentioned this pull request Apr 12, 2020

rustc_target: Refactor target specifications related to Windows and UEFI #71030

Merged

Implement flexible target specification #16156

Implement flexible target specification #16156

Uh oh!

Conversation

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

huonw commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

errordeveloper commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

emberian commented Aug 1, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mneumann commented Aug 1, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emberian commented Oct 29, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vadimcn commented Oct 30, 2014

Uh oh!

aturon commented Oct 31, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vadimcn commented Nov 2, 2014

Uh oh!

emberian commented Nov 3, 2014

Uh oh!

alexcrichton commented Nov 3, 2014

Uh oh!

vadimcn commented Nov 4, 2014

Uh oh!

Uh oh!