对于我的 iOS 和 OS X C++ 库，数据类型 unsigned long 在 64 位环境中会导致问题。它在 32 位架构中运行良好。在 GCC 中阅读 -mx32 编译器标志，它将所有 64 位数据类型处理为 32 位。在适用于 llvm 的 iOS 和 OS X 中，是否存在任何此类标志来支持无符号长，就像在 32 位架构中一样。 我尝试在 Compliter Flags 部分添加 -mx32 标志，仍然 unsigned long 的大小打印为 8。
谢谢。
【问题讨论】：
long 的大小由平台 ABI 定义。 Apple 已宣布您必须支持他们的 64 位 ABI：
在 WWDC 2017 上，我们宣布从 2018 年 1 月开始，提交到 Mac App Store 的新应用程序必须支持 64 位，并且从 2018 年 6 月开始，Mac 应用程序更新和现有应用程序必须支持 64 位。如果您在 Mac 之外分发应用程序App Store，我们强烈建议分发 64 位二进制文件，以确保您的用户可以继续在未来版本的 macOS 上运行您的应用程序。 macOS High Sierra 将是最后一个不折不扣地支持 32 位应用程序的 macOS 版本。
提醒一下，提交到 App Store 的新 iOS 应用和更新必须支持 64 位。 iOS 11 不支持 32 位应用程序，并且之前安装在用户设备上的所有 32 位应用程序都不会启动。如果您尚未在 App Store 上更新您的应用程序以支持 64 位，我们建议您提交更新，以便您的用户可以继续在 iOS 11 上运行您的应用程序，这将在今年秋季为数亿用户所用.
这意味着回到仅 32 位的构建在短期内不会奏效。理论上可以构建一个外部具有 64 位 ABI，但内部具有不同类型大小的自定义编译器。 OpenJDK 在内部执行此操作，并且 GNU 工具链在 x86-64 上支持非常相似的东西（尽管它仍然需要内核支持，所以它不是 Darwin 的选择）。但这需要大量工作，并且需要对系统标头进行大量调整。
不幸的是，最好的办法是将软件中的unsigned long 替换为便携式类型，例如uint32_t。
【讨论】：