Skip to content
This repository was archived by the owner on Mar 1, 2019. It is now read-only.

Try to get the target triple from rustc itself #160

Merged
merged 2 commits into from
Jan 12, 2019

Conversation

cuviper
Copy link
Contributor

@cuviper cuviper commented Dec 13, 2018

The prior method was trying to pick the triple out of the sysroot path.
A FIXME comment already notes that this doesn't work with custom
toolchains in rustup. It also fails with distro-installed toolchains,
where the sysroot may simply be /usr.

The output of rustc -Vv is a more reliable source, as it contains a
line like host: x86_64-unknown-linux-gnu. This should be enough to
identify the triple for any rustc, but just in case, the path-based
code is kept as a fallback.

The prior method was trying to pick the triple out of the sysroot path.
A FIXME comment already notes that this doesn't work with custom
toolchains in rustup. It also fails with distro-installed toolchains,
where the sysroot may simply be `/usr`.

The output of `rustc -Vv` is a more reliable source, as it contains a
line like `host: x86_64-unknown-linux-gnu`.  This should be enough to
identify the triple for any `rustc`, but just in case, the path-based
code is kept as a fallback.
@cuviper
Copy link
Contributor Author

cuviper commented Dec 13, 2018

Note, it's already a bit of a problem to assume that the host/toolchain triple matches the target. That appears to be part of the cross-compilation issue rust-lang/rls#309. Eventually, I expect the real target triple should be communicated directly, but for now this PR should still be an improvement.

Copy link
Collaborator

@Xanewok Xanewok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's definitely an improvement, thanks. I assume the logic at

let sys_root_path = sys_root_path();
let target_triple = extract_target_triple(sys_root_path.as_path());
let libs_path = sys_root_path
.join("lib")
.join("rustlib")
.join(&target_triple)
.join("analysis");
will continue to work for /usr or similarly globally installed toolchains?

@cuviper
Copy link
Contributor Author

cuviper commented Dec 14, 2018

I assume the logic at [...] will continue to work for /usr or similarly globally installed toolchains?

Yes, /usr is my primary motivation as a Fedora & RHEL packager. :)

However, there's still some assumption in {sysroot}/lib/rustlib/... in that /lib/, which may be something else if the toolchain was built with ./configure --libdir PATH or [install] libdir = "PATH" in config.toml. Early on I did use this in Fedora, where 64-bit wants /usr/lib64, but I stopped because it was often fragile in the old makefiles and in rustbuild. I don't know if other distros currently change libdir, but I also don't know anyway to discover the configured path.

I'll add a FIXME comment noting this, at least.

@cuviper
Copy link
Contributor Author

cuviper commented Jan 10, 2019

Anything else for me to do here?

@nrc
Copy link
Member

nrc commented Jan 12, 2019

Anything else for me to do here?

Doesn't look like it, sorry for the delay and thanks for the reminder!

@nrc nrc merged commit bd82c9b into rust-dev-tools:master Jan 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants