对于即将进行的项目，计划将在Windows和Linux上编译的现有C ++代码移植到MacOS(leopard)。该软件是命令行应用程序，但可能计划了GUI前端。 MacOS使用g ++编译器。通过使用与Linux相同的编译器，似乎不会有任何问题，但是总会出现。

在港口期间是否有任何需要注意的建议或者问题？

解决方案

我们尚未移植到MacOS，但是已经从Linux移植到各种Unix，主要工作领域是安装和启动系统，因此希望将大部分工作放在那儿(假设我们现有的东西已经可以在Linux之间移植了)和Windows)。

应用程序是否具有GUI，以及哪个GUI(本机/ Qt / Gtk +)？

如果不是这样，则需要注意的问题(与Linux相比)主要在动态链接区域。 OS X使用'-dylib'和'-bundle'，实际上有两种动态库(运行时可加载库和普通库)。 Linux只有一种(共享的)，并且无论如何都比较宽松。

如果应用程序具有GUI，则需要使用Objective-C在Cocoa中重新编码整个代码。意味着我们也将使用一种新的语言。有些人(例如MS)已使用Carbon(C ++ API)，但正在逐步淘汰。我不建议在新项目中使用。

最好的选择是使用Qt或者Gtk +。几天前已经(重新)宣布了本地Gtk +端口(请参阅Imendio)。

p.s.
OS X当然也可以运行X11二进制文件，但是将其推送给任何客户可能都很难。他们习惯了Aqua界面，并因此而富有成效。仅将X11视为短期解决方案。

p.p.s. OS X附带的开源插件库的数量是有限的，其版本可能会落后。在Linux中，我们可以轻松地要求用户安装" libxxx v.y.y"，而在OS X中，有多种打包方法(fink，macports)，对于商业工具，所需的库应包含在应用程序中。 OS X为此提供了"应用程序捆绑包"和"框架"(本地副本，使应用程序自给自足)。 Linux没有这样的概念。这也将对构建系统产生很大的影响。也许我们会想要在所有平台上尝试类似SCons的东西？

Macintosh(macosx)本质上是FreeBSD的内幕(尽管已对其进行了调整)。 Linux和FreeBSD之间在系统编程方面存在一些差异。这些差异主要存在于各个系统调用之间……因此，对影响将由应用程序执行情况以及执行期间执行的OS系统类型决定。

我们无需将所有内容重新编码为Objective-C。 C ++和Objective-C有一个奇怪的混蛋，使我们可以使用Objective-C中的C ++代码，因此我们可以智能地拆分C ++中的模型代码和Objective-C中的视图/控制器代码。要使用Objective-C，只需在源代码文件后缀.mm而不是.m，并且即使在同一行上，我们也可以混合大多数合法的C ++和Objective-C语法。