使用 Clang/LLVM 修复使用 Android NDK 18+ 的 building jnidispatch

更多的是一个讨论的地方，而不是一个需要立即解决的问题，因此我特别没有做出任何公共关系活动，因为这还没有经过全面测试。如果有任何人在其他项目中有 libffi 经验，知道从 gcc 到 clang 的任何技巧，那将会非常有帮助。无论如何，这是一个带有我建议的修改的分支：https://GitHub.com/BugsBeGone/jna/commits/android-ndk-llvm/ 实际提交，如果分支被重新基准化以同步与 master，则可能已过时：https://GitHub.com/BugsBeGone/jna/commit/2be472422f4ea1c479ef1322253b9a1ab7d356e0 一些初步观察： - ARMv5 和 MIPS（32 和 64）目标在 NDK r17 中被删除。理论上，Play Store 仍然支持可以在这些架构上运行的 Android 版本，因此如果旧工具链仍然可以使用，那么现在完全删除它们还为时过早。至少我希望一个主要的 JNA 版本升级可以表明已删除的目标（编辑：我认为这些库总是可以使用旧 NDK 构建，在这种情况下，不需要通过删除支持来引发突变。）- 独立工具链在检测版本方面是一团糟。我无法想到不涉及用户手动设置 NDK 主版本或 USE_CLANG 定义来确定要使用哪个编译器套件的方法。我赞成正式不支持使用独立工具链，因为您需要大约 1GB 的额外磁盘空间每个目标，因此即使测试也很麻烦。- 更确切地说， r17 到 r21 之间的 NDK 通常似乎不稳定，需要不寻常的 GCC/Binutils 和 Clang/LLVM 组合才能正常工作。由于现有的构建环境从未与 r15 之后的任何东西一起工作，因为切换到 统一头文件，我们可能不需要太担心，只要每个人都愿意从 r15 跳到 r22。我主要是使用 NDK r27c 进行测试，因为这是最新的 LTS 版本（编辑：r27d 仍然是最新的 LTS，与 r27c 的唯一区别是对 macOS 进行了一些修复）。