Hi! My company has been building with Rust to create a cross-platform SDK and iOS is a major market. We have been trying to figure out how to make bitcode support work, following the various threads: https://github.com/rust-lang/rust/issues/35968. It seems there is an incompatibility with LLVM and there is a general challenge in keeping up with the changes Apple makes. We would be happy to help but are not sure where to start. Furthermore, our company would be willing to financially support the effort entirely if someone else can assist? Who would be the best to talk to about this? Thanks!
This is a difficult issue for officially distributed rustc, but I think it should be fairly easy to match the versions if you compile rustc with
system-llvm support; if apple allows for that, at least.
Do keep in mind that whenever you're shipping a rustc linked against an unusual LLVM version, the bulk of the difficulty is not making rustc compile but finding & handling the various small bugs which invariably exists in any given snapshot of LLVM. rustc-picked LLVM has ab about as many as any other random revision, but there's a rather big community testing it, filing bugs, minimizing reproducers, and importing the bug fixes that happen upstream. If you ship a rustc with a different LLVM, you're more on your own with those tasks.
Thanks for the replies, sorry I didn’t have notifications to see them! I will try compiling with older LLVM but my real hope was to get something more built in for this and to enable it for others since it is clear from the issues this is a deal breaker for some looking at the language. Do you see anyway that this could be possible?
Petition Apple to either use a stock LLVM or make public (or at least linkable) their LLVM.
As long as Apple has no intent on allowing other languages be first class citizens on iOS devices, it will not happen.
That’s disappointing since I assume you know how tall of a request that is. If there was a way to get the community to test when each new build of Xcode came out, this seems a bit more achievable?
The problem is IIRC is that you cannot link to the Apple’s LLVM at all in the first place, because they do not ship something necessary to do that. We can try linking to a similar version of LLVM, but since apple modifies their own, it is likely that those versions will be incompatible in one way or another.
I know I originally suggested
use-system-llvm but I had forgotten about that particular detail back then
This overall means that for a good support of this use-case we need to get Apple to make it possible to link to its LLVM.
otherwise you will end up threading a thin line which might not appear to be broken based on the superficial testing we could do.
I still think that
use-system-llvm with whatever workarounds necessary to make it work, will be the best way forward for anybody wanting to pursue this use-case
(this might involve e.g. using the header files from public LLVM and attempting to link against apples llvm dylib, if it exists at all)
(if it doesn’t then all the bets are pretty much off)
Ok that helps clarify, I had forgotten that there is a potential distinction between what Apple is using and public. Thank you for discussing.
Just wanted to share that we published this toolchain to help others with bitcode: