Use apple's version of clang to compile iOS targets by default

457effd
Opened by Michael Eisel at 2023-03-04 00:34:03

In Xcode, Apple ships a closed-source version of clang, which in turn has a closed-source version of LLVM (it seems like Xcode 9's LLVM forks off of LLVM 5?). Apple's clang/LLVM generally includes stability enhancements that would otherwise potentially cause problems for developers. I'm not sure what the benefits are of using Rust's current LLVM, e.g. it can be newer than Apple's, but Apple's clang is a really safe bet and seems a good thing to use by default. Some of these platform-specific issues can manifest in weird and very difficult to diagnose ways, e.g. random restarts, that it would be good to save developers from.

We could just give users a bitcode file for them to compile with clang themselves (#35968), or maybe there's some way to have the user specify which version of clang they want.

  1. I guess we should probably add OS X targets as well

    Michael Eisel at 2018-03-08 06:15:30

  2. I've never heard of something like random restarts being caused by compiler issues (especially for an unprivileged userland app!)… and I don't think stability enhancements are the main reason Xcode has its own LLVM fork. But there have been cases where features show up in Xcode's LLVM before LLVM trunk - such as the entire arm64 port, when it was originally developed, because Apple wanted to keep it secret that they were planning to ship arm64 devices. And since producing bitcode compatible with Xcode LLVM is desirable anyway due to #35968, I suppose it wouldn't hurt to always use it to compile... Still, I'm not sure it's necessary.

    comex at 2018-03-08 06:41:28

  3. @michaeleiselsc / @comex do y'all know what something like this would entail? Do we need to stop compiling code like libbacktrace and/or other C code as part of libstd? Is this purely as a code generator step? Or is this purely to align LLVM versions so the bitcode is compatible?

    We don't actually use clang anywhere in rustc itself at build time, but we do use LLVM! The version of LLVM that Rust is using may be somewhat difficult to align with OSX's, however, as that means that we'd have to ship a version of rustc per Xcode, right?

    Alex Crichton at 2018-03-08 17:25:00

  4. @comex I can't go too far into the details of what has been merged into Apple's clang/LLVM on this public channel for security reasons, but I'm happy to discuss privately. But an app I was working on got hit hard by random restarts in December 2016, and it's caused by a specific issue that open-source LLVM only fixed December 2017. When we moved from open-source LLVM to Apple's LLVM in December 2016, the problem was fixed.

    Michael Eisel at 2018-03-08 21:57:26

  5. @michaeleiselsc I'd like to hear more to clarify what's going on. Can you email me at comexk@gmail.com? Thanks very much…

    comex at 2018-03-09 02:28:37

  6. Well, I had a chat with @michaeleiselsc, and what he's talking about is the real deal - there really was a stability patch in Xcode's LLVM that didn't show up in the open source version for a long time. I apologize for being skeptical. That said, considering how many other things use open source LLVM on iOS - including, say, Apple's Swift development snapshots, which you can use directly from Xcode - I'm still not sure if it's really necessary to do something hacky to access the system's codegen.

    On the other hand, the most difficult requirement, aligning rustc's LLVM version with Xcode's, is separately desirable in order to properly support embedded bitcode, and it would have the side benefit of enabling LTO between Rust and C.

    I'll probably write more about this when I'm less tired.

    comex at 2018-03-09 05:27:04

  7. @alexcrichton as a temporary solution, how risky do you think it would be to build 1.24.0 on my OS X machine with LLVM 6? Would it be more or less risky than using 1.25, which, correct me if I'm wrong, has LLVM 6 already?

    Michael Eisel at 2018-03-12 22:26:35

  8. @michaeleiselsc I don't think we had any major bug fixes for iOS/OSX, so it should hopefully work roughly alright! If something in src/rustllvm (our C++ shims) doesn't compile you can probably just copy the current shims on master

    Alex Crichton at 2018-03-13 14:21:42

  9. @comex it turns out that we've been using a patched version of clang 5 with the restart bug fixed, and I guess there haven't been any disastrous consequences. So perhaps using LLVM 6, which has the restart bug fixed already, will get us close enough

    Michael Eisel at 2018-03-14 15:48:29

  10. @michaeleiselsc did you end up making progress on using the Xcode/system LLVM for your project?

    Adam Perry at 2018-05-16 23:01:39

  11. we have a related problem (llvm version mismatch) when trying to run nm on rust static lib with xcode 12.5 (compiler_builtins-bc8e57a7c90d33c8.compiler_builtins.4d5ea41f-cgu.0.rcgu.o) Unknown attribute kind (70) (Producer: 'LLVM13.0.0-rust-1.56.1-stable' Reader: 'LLVM APPLE_1_1205.0.22.11_0') The same problem does not occur on xcode 13.1

    Brian Johnson at 2022-01-17 01:11:22

  12. Note: Apple has deprecated bitcode in Xcode 14.

    Jubilee at 2023-03-04 00:34:03