Oh, is there no more extra step nowadays in making sure you have a linker, a copy of libc, the right environment variables, or whatever else might be missing? (Some (possibly old) tutorials I came across and glanced at suggested as much… and I don’t have a Mac to test.)
I think it's out of the box nowadays with Rust-only code and Linux specifically? There have been rough spots with the Mac version of lld etc, but my impression was so long as you don't have any C code to compile the toolchain is self-contained.
Iirc, due to licencing, this isn't true for targeting Mac and Windows, as rustup can't bundle their libraries, but there's work to fix this by letting the winapi crates of the world embed the needed linking details.
Do you mean that the target directory I built on the Mac generates an executable file corresponding to the Mac? If I put it on Linux, It is an executable binary file with wrong format. Correspondingly, install the corresponding version of the build tool on Linux and build it under the directory
1 Like
Yep, exactly.
By the way, I forget if the default linker on Mac works right now for cross compilation, so you might need this in .cargo/config.toml under your project:
[target.x86_64-unknown-linux-gnu]
linker = "rust-lld"
Edit: Also, apparently it might just be rustup target add x86_64-unknown-linux-gnu instead of rustup toolchain install .... it's 2 in the morning and I'm on my phone - no warranty provided with these instructions! 
1 Like
ok I'll try Thanks Simon
@protalker123 @steffahn @simonbuchan
If the whole project is run on a Linux server, there is a problem. At least in my area, because when cargo is running, it will pull crates.io dependency I remember that I reported a problem a while ago because of crates.io synchronization in my region is very slow, so it needs to wait a lot of time when running, and it may not build succeed.
I think the best way is to package and compile the dependent files into the target directory, compile the executable files and put them on the server without synchronizing the crates.io dependency.
You might be able to change the cargo configuration in the same way as you do on your local machine to use a faster-to-access mirror of crates.io.
Another alternative to avoid the need to internet connection is to work with cargo vendor in order to “manually” transfer the source for the dependencies to the server, too.
Run cargo vendor on your machine and update the project’s config on the server (/path_to_project/.cargo/config.toml) according to the output of the cargo vendor command; then transfer the project including your source code and the generated vendor directory as well as the relevant config directory to the server; (on the other hand, you do not need to indlude the target directory).
creation of vendor folder and config, e.g.:
mkdir .cargo
cargo vendor > .cargo/config.toml
If you then build the project on the server (after transferring its source, including the vendor and .cargo directories, as described above), this built process should not require any further internet access at all.
3 Likes
Yes, I think the change source can be replaced without publishing on the server, but the source in our region is not up-to-date. Sometimes it's a headache if it can't be pull, but thank you very much.
Fortunately, I have run success on the server, but the result is not very ideal
A third option is to use a virtual machine or docker to run a compatible Linux locally, and build it there. It can be a much bigger pain to actually develop with, but it deals with C code and other edge cases a lot easier.
4 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.