KMP 和 XCode26
iOS 最近打包机已经升级 xcode26，突然出现了 kmp 相关的编译问题，包括一些头文件 not found 和 unresolved classifier 等等的问题
因为，我们的 kotlin/native 编译器基于 kotlin 2.0.21 做了魔改，用于支持鸿蒙系统，而且整个主工程的 kotlin 也没法轻易升级，所以直接升级 kotlin 2.2.20 官方支持的 xcode26 版本，短时间是不现实的
所以，需要想办法在 kotlin 2.0.21 的基础上支持 xcode26
Kuikly 写在前面
Tencent Kuikly Kotlin 已经适配 xcode26，如果没啥特殊需求定制的话，可以直接使用
https://github.com/Tencent-TDS/KuiklyBase-kotlin/commit/56b5c978e857dc9bcbccd4d66055b618fda7040e
作者说修改集中在 llvm 部分，但是 llvm 修改的部分似乎没有公开
猜测是他们需要编译一份独立的 llvm/clang 12.0.1，这个版本的 llvm 在 xcode26 的高版本的 clang 下编译是有问题的，所以需要修改
之前，我也基于 llvm 12.0.1 魔改了较多代码，让其可以在高版本的 clang 下编译通过
修改涉及了众多文件，如下：
但是，最终没敢用我自己魔改的 llvm(腾讯修改的 llvm 应该会比较靠谱…吧)，原因是：
- 修改了很多神奇的地方，不确定正确性，不敢提交(对 llvm/clang 了解有限，很多地方借助 AI 辅助)
- 我们做了编译上的隔离，只有 ohos 才会使用到 llvm/clang 12，而其他的都还是 llvm 11.1.0，而且 xcode 其实也只是影响 apple 系的东西，所以也可以考虑修修补补 llvm 11.1.0 上遇到的问题
基于 llvm 11.1.0 适配 XCode26
既然想基于 llvm11.1.0 适配，那我们就看看到底在编译 kotlin/native 编译器的过程中有什么问题，并一个个解决
‘UIUtilities/UIDefines.h’ file not found
因为并不是 iOS 开发，搜索了一些文章和本地 sdk 后发现，UIUtilities 被移动到了 subframework
在 ClangArgs 中添加 -F path/to/SubFrameworks 解决
-lto_library library filename must be ’libLTO.dylib’
似乎是 toolchains 升级以后，linker 有变化？
总之，按照它的要求 -lto_library 后添加 libLTO.dylib
因为有多个地方的 build.gradle 有类似的写法
linkerOpts("-Xlinker", "-lto_library", "-Xlinker", "KT-69382")
// 修改为
linkerOpts("-Xlinker", "-lto_library", "-Xlinker", "$llvmDir/lib/libLTO.dylib")
modulemap 问题
类似如下报错
module '_c_standard_library_obsolete' requires feature XXXXX
包括 stddef.h 相关头文件中的 size_t 等等问题，似乎也是 clang feature 相关的问题，导致了 use_clang_def 的宏定义有问题，头文件不会被引入，或者高版本有了其他修改，就应该不被引入？
这块的修改不确定是否正确
因为 modulemap 中的 _c_standard_library_obsolete require 相关语句导致了编译报错，所以我将 modulemap 还原为了头文件引入的方式
大致就是根据 moduleName 和 modulemap 中的 header 文件，拼接为原本的头文件路径，如 XXXModule/XXX.h
这样以后，重新拼装 includes 传递给 buildNativeLibrary 即可绕过此问题
Accelerate.def 问题
这个我尝试修改了下，似乎是高版本多了个参数定义，但是不确定怎么传进去，或者说，具体传哪个值？
所以，干脆把这个模块 disable 掉，不进行 interop，绕过
总结
kotlin/native 的方案目前还是有很多问题，比如崩溃问题解决起来也是只能挠脑壳子，还要不停的适配 xcode，如果是国内团队还要适配鸿蒙
幸运的是，有腾讯帮忙做适配
所以，如果是小团队想试用，写写三段逻辑，建议直接用 kuikly 的 kotlin 编译器，同时，写 UI 的话，也有 Kuikly UI 和 ovCompose(支持 compose multiplatform 在鸿蒙上渲染)。如果是大团队，人力充足，那就自己卷吗
本人很不幸，团队人员稀少，还要卷这些东西，脑细胞已经死绝，后续打算直接投入 kuikly kotlin 编译器的怀抱好了