At a first glance, Rust's --target option seems like a very convenient way to build your project for various targets. But when you actually try to use it, it quickly turns out that this does not work most of the time for any --target other then than your current build platform

For example, I am building on a Linux (64-Bit) system and I want to use --target=x86_64-unknown-freebsd to create a FreeBSD binary, but this fails with:

error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-unknown-freebsd` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-freebsd`

Fair enough! So I do exactly what Rust told me and I run:
rustup target add x86_64-unknown-freebsd

But it still fails! This time with a cryptic error message and no hint what to do:

error: linking with `cc` failed: exit status: 1
  |
  = note:  "cc" "-m64" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/x86_64-unknown-freebsd/lib/libcompiler_builtins-*.rlib" "-Wl,-Bdynamic" "-lrt" "-lutil" "-lexecinfo" "-lkvm" "-lmemstat" "-lkvm" "-lutil" "-lprocstat" "-lrt" "-ldevstat" "-lexecinfo" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lrt" "-lutil" "-lexecinfo" "-lkvm" "-lmemstat" "-lkvm" "-lutil" "-lprocstat" "-lrt" "-ldevstat" "-L" "/tmp/rustcvkABXZ/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-o" "/home/me/src/app/target/x86_64-unknown-freebsd/release/deps/app-e6f8145791fa06db" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-all" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /usr/bin/ld: cannot find -lexecinfo: No such file or directory
          /usr/bin/ld: cannot find -lkvm: No such file or directory
          /usr/bin/ld: cannot find -lmemstat: No such file or directory
          /usr/bin/ld: cannot find -lkvm: No such file or directory
          /usr/bin/ld: cannot find -lprocstat: No such file or directory
          /usr/bin/ld: cannot find -ldevstat: No such file or directory
          /usr/bin/ld: cannot find -lexecinfo: No such file or directory
          collect2: error: ld returned 1 exit status

What does this mean?

Did I do something wrong? Did I encounter a bug in Rust? Impossible to know!

At this point I can only give up. Or look for bug reports on GitHub of people who ran into the same problem. I did the latter and, as it turns out, I need to install clang and I need to explicitly tell Rust to use it by adding -Clinker=clang to the RUSTFLAGS. Plus, I also need to pass the correct target to clang by adding -Clink-arg=--target=x86_64-unknown-freebsd too.

Why, if Rust needs to use clang for --target=x86_64-unknown-freebsd to work, it doesn't tell me so? Why it doesn't tell me that I need to install clang, just like it did tell me that I need to install the target via rustup? And why it doesn't automatically use clang, once it is installed? Finally, why do I manually need to add the completely redundant -Clink-arg=--target=x86_64-unknown-freebsd to RUSTFLAGS when I'm already building with --target=x86_64-unknown-freebsd and therefore Rust shall be able to forward the correct parameters to clang by itself?

And the journey doesn't end here! Even with all of the above, Rust still fails to build. The missing piece again is an information that can only ever be found by reading through bug reports on GitHub: We need to download a so-called "sysroot" from the FreeBSD web-site, extract it to our Linux system and add -Clink-arg=--sysroot=/sysroot/freebsd/amd64 to the RUSTFLAGS. Sorry, but how in the world can anybody be expected to figure out that? If building with --target=x86_64-unknown-freebsd necessarily requires the matching "sysroot", then why (why?) Rust doesn't tell me so? Or, even better, why rustup target add does not simply download + install the "sysroot" stuff that it is inevitably going to require anyway?

Conclusion: At this point Rust's --target option is a big mess that is next to impossible to use right. Error messages are absolutely cryptic, and hints on how to fix them are lacking. Much of this could easily be avoided if Rust would automatically be doing the right things that are inevitably required anyway – rather than forcing the user to figure out obscure workarounds, which can only ever be found by reading through the bug reports on GitHub...

Are there any chances that this will be improved ???

Cheers!

6 posts - 5 participants

Read full topic