Skip to content

Use correct host triple #2400

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

Closed
catamorphism opened this issue May 17, 2012 · 3 comments
Closed

Use correct host triple #2400

catamorphism opened this issue May 17, 2012 · 3 comments
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler

Comments

@catamorphism
Copy link
Contributor

FIXME in driver::driver::host_triple says:

    // FIXME: Instead of grabbing the host triple we really should be
    // grabbing (at compile time) the target triple that this rustc is
    // built with and calling that (at runtime) the host triple.
@ghost ghost assigned lht May 17, 2012
@brson
Copy link
Contributor

brson commented Jan 29, 2013

After running into this comment I'm surprised that this hasn't caused any noticeable fallout. The result of this should be that our i386 compilers think that they are x86_64 compilers.

@graydon
Copy link
Contributor

graydon commented Apr 24, 2013

this comment is still present, but the logic has changed; it is now grabbing the build triple from the compilation environment, which might well be correct. I suspect all this needs is some cleanup and clarification (possibly renaming the method)

bors added a commit that referenced this issue May 29, 2013
Most of the relevant information can be found in the commit messages.

r? @brson - I just wanted to make sure the make changes aren't completely bogus

This would close #2400, #6517, and #6489 (although a run through incoming-full on linux would have to confirm the latter two)
@alexcrichton
Copy link
Member

I believe that this can be closed now. I tried to clarify as well where necessary. If anyone feels that it's wrong to close, feel free to reopen!

Manishearth added a commit to Manishearth/rust that referenced this issue Jun 20, 2015
…pnkfelix

As per rust-lang#26009 this PR implements a new collation system for extended-error metadata. I've tried to keep it as simple as possible for now, so there's no uniqueness checking and minimal modularity.

Although using a lint was discussed in rust-lang#26009 I decided against this because it would require converting the AST output from the plugin back into an internal data-structure. Emitting the metadata from within the plugin prevents this double-handling. We also didn't identify this as the source of the failures last time, although something untoward was definitely happening... With that in mind I would like as much feedback as possible on this before it's merged, I don't want to break the bots again!

I've successfully built for my host architecture and I'm building an ARM cross-compiler now to test my assumptions about the various `CFG` variables. Despite the confusing name of `CFG_COMPILER_HOST_TRIPLE` it is actually the compile time target triple, as explained in `mk/target.mk`.

```
# This is the compile-time target-triple for the compiler. For the compiler at
# runtime, this should be considered the host-triple. More explanation for why
# this exists can be found on issue rust-lang#2400
export CFG_COMPILER_HOST_TRIPLE
```

CC @pnkfelix @brson @nrc @alexcrichton 

Closes rust-lang#25705, closes rust-lang#26009.
tshepang pushed a commit to tshepang/rust that referenced this issue Jun 2, 2025
Make it clear we talk about early bound params
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler
Projects
None yet
Development

No branches or pull requests

5 participants