这是我有关交叉编译的系列文章的第3部分。 您可以先检查第1部分和第2部分！
您不能满足Windows和Linux用户的需求，而忽略了第三种主要的第二种桌面操作系统。
我所说的操作系统当然是由一家最著名的公司开发和商业化的，该公司将Clang推向世界，主要负责维护WebKit（在大多数行业转移到Chromium之后），并创建了其他一些令人惊奇的开源软件，例如CUPS。
为此，我们应该感激不尽。
您可能会认为，如果一家公司想启动一个全新的编译器以提供更好的用户体验而遇到麻烦，那么可以轻松地对其平台进行交叉编译。
然而。
那家公司是苹果。
像在Linux和Windows上一样，我们将需要获取并设置3个组件。 用于桌面集成的编译器，一些系统头文件和库（如libc++和Sdk。
如果您以前已经完成过OS X的开发，那么您就会知道XCode可以找到所有功能，XCode是5GB的捆绑工具包，我们大多数都不需要。
XCode是免费软件。 如在啤酒中。 我们将需要很多。 XCode是专有的，这很好。
问题是，如果您阅读XCode附带的条款和条件 ，则会发现以下子句。
2.7限制； 没有其他允许的使用本协议中的授予不允许您，并且您同意不允许在任何非Apple品牌的计算机或设备上安装，使用或运行Apple软件或Apple服务，或使他人能够这样做。
我不是律师。 但是，在我看来，无论技术能力如何，Apple都在积极禁止使用其库进行交叉编译。
因此，本文其余部分讨论的某些想法（如果适用）可能会使您与Apple达成的任何协议无效。
您需要一个Apple ID，因此您需要在apple.com上创建一个帐户。 我不记得曾经有过更糟糕的帐户创建经验。 最大的罪行当然是他们过时的安全策略。
然后，他们会给您发送电子邮件进行验证，这很棒。 但是，除了在电子邮件中没有链接之外，您还会得到一个甚至无法粘贴的代码，而必须手动输入。
然后，您将搜索XCode。 幸运的是，自2012年以来，一些优秀的撒玛利亚人在Stackoverflow上保持有效的下载链接 。
这再次变成了“所有软件都很糟糕”的咆哮。 对不起。
更积极的一点是，有人已经建立了一个不错的脚本集合，以帮助您开始在Unix上构建OsX工具链。 也可以与Cygwin合作！
您将需要克隆它。
这是我必须修补的ThomasPöchtrager作品的叉子。
XCode 7.3是DMG附带的，虽然这是osx专用的文件格式，但osxcross附带了一个脚本来提取它，很好地利用了Darling 。 以后再说。
osxcross/tools/gen_sdk_package.sh Xcode_xxx.dmg
不幸的是，开源社区仍在等待苹果发布支持TBD文件v2的ld64链接器，该文件在更高版本的osx中使用，而不必在sdk中附带.dylib。
TBD文件非常酷，它们是动态库中包含的符号的YAML表示形式，从而减少了实际库的发布需求。 它们在概念上与构建DLL时由MSVC生成的.lib文件非常相似。 我认为TBD文件可以在各种平台上使用，但是现在LLVM无法处理它们（还？） ，而开源ld64无法处理新版本。
因此，我们必须坚持使用10.11 SDK。 这是合理的！ 我不得不支持用于打包更高版本XCode的xip文件。 这种格式的灵感来自babushka娃娃，但压缩了档案。 不幸的是，我们不能使用比XCode 7.3更新的东西。 我希望它会很快改变！
然后，您可以运行将生成的MacOSX10.11.sdk.tar.xz移至osxcross/tarballs然后启动SDK_VERSION=10.11 ./osxcross/build.sh
您还需要运行osxcross/build_llvm_dsymutil.sh
而且，您将立即获得适用于i386和x86_64 OSX的完整工具链（即使在使用OSX时，您绝对有0个理由以32位构建任何内容）。
它甚至建立了我个人的最爱： otool和install_name_tool 。 如果您曾经在OSX上构建过某些东西，您就会知道这些工具是多么糟糕。 更确切地说，OSX加载程序多么糟糕。
我对osxcross的工作印象深刻。
配置QBS非常简单，尽管有些事情要注意。
在osxcross/target/bin ，运行：
ln -s x86_64-apple-darwin15-ld ld
cp osxcross-llvm-dsymutil x86_64-apple-darwin15-dsymutil
这将在以后帮助clang找到合适的工具。 如果要支持多个工具链，请将ld放在子文件夹中
这是我的配置文件，您无法适应
-prefix选项告诉clang在哪里可以找到正确的ld （ld64），因为系统链接器不适合链接Mach-O应用程序。
其余的只是给qbs正确的搜索路径。
不幸的是，qbs中对.plist的支持不是可移植的，因此您将遇到错误
ERROR: TypeError: Result of expression 'PropertyList' [[object Object]] is not a constructor.
at JavaScriptCommand.sourceCode
at Rule.prepare in /opt/qtcreator/share/qbs/modules/cpp/DarwinGCC.qbs:262:18
注释掉DarwinGCC.qbs中的规则以解决此问题。
当然，无法创建info.plist文件将受到很大限制，如果QBS能够以与平台无关的方式处理这些文件，那就太好了。
现在，在我们所有的.qbs项目文件中，我们将放置以下内容禁用捆绑功能，从而禁用Info.plist生成
Depends {
name: "bundle"
}
bundle.isBundle: false
到那时，我们可以构建简单的控制台Hello World，在第一部分中可以看到
# file helloworld
Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE>
但是可以运行吗？
哦，亲爱的 ！
为了运行Windows应用程序，我们使用了wine。 最近有一个努力-它始于2012年，而WINE始于1993年； Windows 3.1刚刚发布！—提供了一个翻译层，称为darling。 该项目还远没有成熟，它似乎没有任何财务支持。 我希望它会流行。
您可以按照github上的说明克隆并构建宝贝。 在我的机器上，整个过程花费了不到一个小时的时间。 安装后，大约为800MB。 这并不奇怪，因为它是一个完整的系统，具有所有常用工具，包括g ++，ruby，python，Perl，git，bash，swift，ssh等。
但是，构建完全没有错误，而且令人惊讶的是，它可以正常工作，并且似乎非常被动。 酒比酒更现代，它是经过容器包装的！
用binfmt添加魔术
因此，现在我们可以运行mac命令，但是如果我们可以将魔术隐藏起来怎么办？
使用内核工具和systemd服务 ，我能够创建文件/etc/binfmt.d/darling.conf以便内核可以处理启动的Mach-O文件。
:Mach-O 64b:M::\xcf\xfa\xed\xfe::/usr/bin/darling_interpreter:
:Mach-O 32b:M::\xce\xfa\xed\xfe::/usr/bin/darling_interpreter:
:Mach-O FAT:M::\xca\xfe\xba\xbe::/usr/bin/darling_interpreter:
/ usr / bin / darling_interpreter是一个启动darling shell的脚本-它应该是可执行的。
#!/bin/bash
/usr/local/bin/darling shell "$1"
亲爱的文档建议， darling <binary>应该可以，但不能。
重新启动binfmt服务（ systemctl restart systemd-binfmt ）后，我们可以透明地启动OSX应用程序。
这意味着我们可以做到这一点
哦，对了，您可以对Windows可执行文件和WINE执行相同的操作。 有些发行版本是开箱即用的。
在第2部分中，我尝试不使用Windows在Linux上安装Qt Framework的win32版本。 我失败了。
没有Mac，我们可以为Mac获得Qt吗？
我确实下载了安装程序。 这是一个.dmg。 这将是一个问题，但是凭借亲爱的力量，我们可以在Linux上安装DMG。 没问题 这是我们在这里所做的事情。
但是，安装Qt安装程序dmg会显示它包含一个二进制文件和一个.dat文件，而不是一个简单的文件夹或可管理的文件。
大概二进制文件就是安装程序。 也许它在宝贝上运行？ 否。对OpenGL框架的严格依赖。
捆绑在糟糕的无法使用的软件包中的出色软件似乎是一个经常出现的主题。
所有的希望再次消失了吗？ 这次不行。
我们可以为Mac构建Qt，就像我们为Windows尝试的那样。 但这会起作用。 Mac已经make 。 它了解clang和gcc，在很多方面都非常类似于Linux。 毕竟那里是UNIX（但是我一直感觉OSX内部很糟糕，隐藏在一个不错的用户界面下。对于初学者来说， 在将上游版本移至GPLv3之后 ， 并没有维护大量工具 ，10几年前 ）。
las，这意味着要处理Qt的复杂构建系统。 花费一些时间破解qmake构建文件。 瞧，Qt做出了可怕的假设，即osx上的所有工具链都包含xcode。 我们没有xcode。
但是，一旦您绕开了所有自动探测和关于系统上已安装什么的假设……。
…。您可以使用它！
#configure -release -opensource -confirm-license -xplatform macx-cross-clang -skip qtwebengine -nomake examples -nomake tests -prefix /home/cor3ntin/dev/cross-compilers/osx/qt5_10
这还不是路的尽头。 Qt Widgets由于缺少依赖项而无法构建。 由于libc ++标头太旧或损坏，因此无法构建QtLocation（我通过在OSX SDK中复制最新的libc ++版本来解决此问题。它起作用了）。 然后QtLocation抱怨，因为未定义std::auto_ptr ，所以我砍了几个标头。
我试图构建qwebengine （chromium），但是它仍然使用另一种构建系统，并且我做了足够多的构建系统黑客工作了一个晚上。
但是最后Qt确实完成了。
然后，我们所拥有的就是相当有趣的东西。 二进制文件是本机Linux ELF，而框架和库是Macho-O。 一分钟内便会很方便。
就操作系统集成而言，Qt是一款大型软件，可以充分利用基础系统功能。 如果我们可以构建它，那么我们几乎可以构建任何东西。
我最初将我的mkspec文件称为darling-clang 。 我是一个坏名字。 这也使qbs不能理解这是Mac版本。 我没有重命名mkspec和重建Qt，而是修改了qbs。 qbs-setup-qt的代码实际上是使用正则表达式解析mkspec的.conf文件。 不知何故，它有效。 只是不要呼吸。
最终，一旦我给qbs期望了解我们正在处理Mac的东西，我就可以打电话给
qbs-setup-qt osx/qt5_10/bin/qmake osx-x64-qt510
其中创建了正确的配置文件和模块。 我手动清理了配置文件以合并clang-osx和osx-x64-qt510
然后我们可以编译或宏伟的Hello World应用程序！
现在怎么办 ？
好吧，我们有一个完整的工具链，也许我们可以检查一些事情？
使用otool -L ，等同于ldd的osx，我们可以断言我们确实链接到某些库
我们可以使用其他工具。 例如nm或strings或可怕的install_name_tool
不幸的是，Darling还不能处理任何远程图形化操作，因此我们需要一台Mac才能真正启动我们的应用程序。
真正的Mac； 可视化Mac OSX是非法的，除非它在Mac上。 我想到了一些话。 想象一下我的法语。
让我们谈谈Mac。 Mac。 您可能知道一个。 大多数公司都有它。
它曾经属于鲍勃。 是鲍勃的Mac。 但是在5年前，鲍勃（Bob）死了，于是Mac被提供给爱丽丝（Alice）。 爱丽丝不久之后离开了公司-也许是巧合。
但是Mac始终是Mac。 它没有主人。 它也没有人偶。 您可以通过ssh bob@mac.yourcompany.com连接到它。 密码只是pass 。 它与在某处虚拟机上运行的其他服务器不在同一局域网中。 无论如何，它都无法进行管理，在一个本来就很安全的网络中提供了方便的后门。
当它运行时。 有时一次下来只有几天。 这不只是人们不在乎，他们也不知道它的实际位置。 Mac mini容易松动。 在某人的桌子下面，楔着一把旧椅子，用作咖啡桌。
上次崩溃时，您不得不连续三天对其进行跟踪，就像在山上追逐一只大猫一样。 您甚至试图给鲍勃的遗ow打电话。
您终于找到了夹在Carol屏幕和牛津词典之间的mac 。 “这是完美的高度！”当您取回她的800美元显示器支架时，Carol表示反对。 您将Mac换成了IKEA的旧目录，而Carol认为它比Mac-Mini实用得多。
您重新插入了Mac ，并努力地将其更新到OSX的最新版本“ Cougar”（或其他类似的东西，很难追踪）。
几天后，当您的同事买了一辆新车，而您失去了家时，我不禁要问：要求信用卡申请免费安全修复程序是否合适？
但是事实是， mac正在发挥重要作用。 运行所有只能在mac上运行的任务。 签署安装程序，执行mac软件包，iOS任务，运行纽约证券交易所……您不确定，毕竟是鲍勃。
如果我们可以虚拟化OSX，也许生活会有所不同。
我确实有一个2011年的Mac-mini，是一位前雇主的礼物。 它的寿命与Mac的寿命有些不同。 从来没有被爱过，并在盒子里呆了近两年。 只能根据本文的需要了解一天中的生活。 这也是为什么我的出版时间表迟到了4天。 我尝试安装High Sierra-灰屏； 我必须重新格式化，安装Lion，然后安装El Captain。 所以El队长就是我们将要使用的。 它具有高达2GB的内存，系统使用了3/4的内存。
您应该在Mac的系统参数中启用VNC，远程共享和SSH。
本文开始有点长。 因此，这是到目前为止已完成工作的直观摘要：
我们应该停止鬼混。
- 在OSX机器上复制Qt的OSX版本。 您可以使用
scp -r，rsync或共享文件夹（通过samba） - 再次使用
scp -r将helloworld-gui复制到计算机上。 - 我们的Qt交叉编译版本不包含
macdeployqt。 您可以通过直接在Mac上安装官方版本的Qt来获得它。 为了避免这样做，并且不具备处理的毛毛乱install_name_tool，我们可以设置DYLD_FALLBACK_FRAMEWORK_PATH使其指向包含所有的文件夹Qt*.framework。 DYLD_FALLBACK_FRAMEWORK_PATH有点理智，但可能不起作用，并且存在一些相关的安全风险。 请不要在发货的应用程序中使用它。
export DYLD_FALLBACK_FRAMEWORK_PATH=/Users/cor3ntin/dev/cross-compilation/qt5_10/lib
- 像在Windows上一样，我们需要在
helloworld-gui旁边提供一个qt.conf文件，以告诉Qt从何处加载其插件（否则该应用程序将不会运行）。 我的看起来像
[Paths]
Prefix=/Users/cor3ntin/dev/cross-compilation/qt5_10/
Plugins=plugins
现在，通过ssh连接到Mac，您可以执行您的应用程序，它将出现在mac屏幕和远程显示/ VNC会话中
我们可以使所有这些合法吗？
Clang，LLVM，ld64和相关工具是开源项目。 这并不意味着开源版本与Apple正在使用的版本匹配。
实际上，Apple的Clang是Clang的正确版本，它们落后于上游几个版本。 考虑到他们开始了该项目，这具有讽刺意味。
LD64和“ cctools”是在“ Apple Open Source许可”下发布的，XCode使用的该工具的版本也比开源社区可以使用的版本提前2年。
框架本身不是开源的，而且正如我在开始时提到的那样，这些框架不可重新分发。
现在仅由Darling令人维持的开源替代cocotron是不够的。
有一些问题
- 他们没有构建脚本来实际构建SDK，而仅安装
.dylib。 这可能很容易解决。 - 他们只有有限的框架集，而这些框架不足以构建Qt。 Qt使用以下框架，以
!!!!为前缀 在达令失踪
* AppKit
* ApplicationServices
!!!! AssetsLibrary
* AudioToolbox
!!!! AudioUnit
!!!! AVFoundation
!!!! Carbon
* Cocoa
!!!! CoreAudio
!!!! CoreBluetooth
* CoreFoundation
* CoreGraphics
!!!! CoreLocation
!!!! CoreMedia
!!!! CoreMotion
* CoreServices
* CoreText
* CoreVideo
!!!! fftreal
* Foundation
* ImageIO
!!!! IOBluetooth
* IOKit
!!!! OpenCL
* QuartzCore
* Security
!!!! SystemConfiguration
- 您可以在OSX上编译Qt Framework，然后将它们复制到Linux机器上，在大多数情况下，它可能会起作用。
- 使用不是官方SDK的SDK可能会破坏交叉编译的目的，以测试您的软件在Mac上的运行情况。 您只是在测试它是否可以在Darling上使用。 无法保证Darling SDK标头与官方标头匹配。 Mingw也遭受该问题的困扰。
因此，从技术上来说，可以跨Linux在Mac上交叉编译复杂的应用程序（包括基于Qt和Qt的应用程序）。 甚至可以直接，无缝地运行非图形应用程序和单元测试。
但是使用SDK会使整个练习变得毫无意义，这是非法的，具体取决于您的法规。 存在开源替代方案，但可能不够充分且不够可靠。
尽管我们可以抱有希望，但令人怀疑的是，苹果公司是否会拥有更多对开发人员友好的政策。
在那可怕的失望中，该结束了！
翻译自: https://hackernoon.com/a-c-hello-world-and-the-rose-gold-walled-garden-of-doom-4ac3c92385ed
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
