$ rustup target add stable-x86_64-apple-darwin
error: toolchain 'stable-x86_64-unknown-linux-gnu' does not contain component 'rust-std' for target 'stable-x86_64-apple-darwin'
note: not all platforms have the standard library pre-compiled: https://doc.rust-lang.org/nightly/rustc/platform-support.html
That's a tier I target. It should work, correct?
Why? It doesn't work any other compiled language, why should it work for Rust?
Apple's position is extra clear: if you want to develop something for macOS or iOS you have to do that on Mac. Period, end of story. Nothing else is supported (and by “unsupported” I mean not “Apple wouldn't help you” but “Apple's license doesn't allow that and there are technical measures in place to make that impossible really hard”).
I know that Visual Studio supports remote development for MacOS, maybe some tools would allow you to do the same with Rust.
But, ultimately, it's just easier to develop MacOS software on Mac. Or ignore Mac completely.
Rust's position seems to be that it should work: Target Tier Policy - The rustc book
If it doesn't work, then x86_64-apple-darwin should be demoted from a tier I target to a lower tier.
Where does your link say that Tier 1 target is supposed to be usable on host of your choosing?
Tiers are about level of support, it doesn't tell anything about your ability to use some random host to use compilers for these tiers.
In fact it specifically tells about this situation: If running the testsuite requires additional infrastructure (such as physical systems running the target), the target maintainers must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team.
I'm not 100% sure but I think it's precisely about MacOS: it wasn't tier 1 platform till Rust project got enough MacOS systems for the CI.
x86_64-apple-darwin is pretty well supported target, you just have to use MacOS if you want to use it.
The target is x86_64-apple-darwin, not stable-x86_64-apple-darwin.
You will also need a compiler toolchain that can target macOS - GitHub - tpoechtrager/osxcross: Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux) is a decent way to do that.
You can also use cross to handle some of the config plumbing for you, though you will need to do some of the work yourself for licensing reasons: GitHub - cross-rs/cross-toolchains: Additional Dockerfiles and crosstool-ng config files to build additional toolchains.
Note that even if you do all that you would still need to get certificate from Apple and use that, or else your apps wouldn't run on normal MacOS setup.
Basically: Apple haven't yet made it impossible to build binaries for MacOS on some other OS, but it becomes increasingly harder each year.
I wouldn't trust these tools, if you really want to provide binaries for MacOS you need MacOS, anything else is just asking for trouble.
That helped. I can install support for that target.
Building the default "hello world" project gets to the point that linking with "cc" fails with the message cc: error: unrecognized command-line option '-arch' Which is kind of strange. cargo generated a cc command that can't work.
cc is (Ubuntu 11.3.0-1ubuntu1-22.04.1) 11.3.0
This is a known problem. Zig seems to be a workaround. That's two years old, though. Is that a good approach?
Read the rest of my post.
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.