-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Support non-host target for cargo install #3810
Comments
Seems reasonable to add |
Cool. Having thought about this a bit more, the underlying issue (compiling for a different native host) affects
In a manner of thinking, this change would make cargo effectively a canadian cross, without all the awful horribleness that involves in c-land... |
I think Cargo should already be all set up for cross compilation (it happens quite a bit normall), the |
Not quite. Cargo does not pass This is a flawed approach. Over many years, and having done many, many cross-compilations and developed approaches to bootstrap entire linux setups from nothing more than gcc, binutils and sh (no, not even make), I've come to the view that it is essential that all compilations are thought of as cross-compilations. Assume nothing. |
Er.. sorry I'm not quite sure I follow :( |
+1 for adding transparent cross-compilation feature to cargo. Do I understand correctly that it intends to cover functionality currently provided by xargo? |
@alexcrichton I think what @raphaelcohn is saying is that:
They're further suggesting that one approach to solving this problem is to pass Does that make sense to you? |
Ah ok, that does sort of make sense. I don't really understand the rationale though because if you're running a compiler with a particular target then you should be able to run a build script with that same target ... |
@aturon I think @alexcrichton Yes you're right if I understand what you're saying. However, Cargo is relying on rustc using a default target - which turns out to be what it is compiled with. And that toolchain may not work correctly on the host itself. A classic example is a glibc-linked rustc running on Alpine Linux. It can itself compile, but the toolchain that implies will produce incorrect binaries that won't run. Being explicit, rather than implicit, is a good practice in most situations, and this is no different. This problem is trivially rectified by having Cargo accept a @anatol This isn't to replace xargo - an excellent tool - but it would play very nicely with it. However, making this change would make it far easier to cross-compile new toolchains when the difference is one of libc settings, location of libc, static vs dynamic, etc. |
To be clear though, this is a hack. This is not how the compiler nor Cargo is supposed to work, and naturally bugs are arising. Also to be clear the real solution to this issue is not this issue itself but rather supporting an x86_64-unknown-linux-musl compiler. My preference would be to not contort Cargo to work around local hacks in the compiler. |
Why is that a hack? It's quite a valid thing to do. There is nothing about Linux, or, indeed, any Unix derivative, that makes it a hack to use more than one runtime linker / libc. Indeed, such a technique has been in use for decades one a vendor supplied binary-only code in the days before open source was so popular. Skype comes to mind. No different to using There aren't any bugs here, but a mistaken assumption. And that is that the toolchain that Cargo was compiled for is the toolchain of the host. Even in the land of madness that is C compilers, they don't force this. It is not a contortion for Cargo, as a compiler driver, to pass explicit arguments to its compiler. And to allow explicit arguments to the build scripts. These are not contortions. They're actually good programming practice, because one is making defaults and assumptions explicit and changeable. |
@raphaelcohn Would you be willing to work on an RFC for this change to the Cargo compilation model? That would give you an opportunity to spell out both the motivation and proposed design in greater detail, and get feedback from the community. |
@raphaelcohn Did you get around to writing that RFC? |
@devurandom No, I didn't - I'm really time poor. I'd be happy to work with you on one if you're interested in doing it, though. |
I believe it was fixed by #5614 |
Closing as no longer relevant. |
On some systems
cargo install
needs to build and install binaries which are slightly different target to itself. For instance, on an Alpine Linux system, I might be using a rustup-installed x86_64-unknown-linux-gnu build of rust with LT_INTERP changed withpatchelf
, but I want to then build and install binaries asx86_64-unknown-linux-musl
. It'd be nice to either have a default host, likerustup set default-host
, or to take a switch--target
likecargo build
.cargo install
seems to ignore environment variables likeCARGO_BUILD_TARGET
, too.This need is also likely on some Windows systems (running i686 and x86_64), multilib Linux systems (eg imagine if a rust binary makes use of a proprietary i686 lib on a 64-bit system), and systems where the user space is usually 32-bit (Solaris IIRC, x64_32 linux).
This need would be mitigated substantially for me personally if rustup deployed a musl-statically-linked toolchain...
The text was updated successfully, but these errors were encountered: