软件开发人员从 Linux 转向 OS X，有哪些问题？

Question 1

几年前我也做过同样的举动。以下是我遇到过的事情：

一般的桌面 Linux 拥有比 OS X 更丰富的用户空间。

您可能会错过与我不同的工具，因此没有必要具体说明替代品的建议。

相反，只需安装芬克,Mac端口，或者自制第一件事。这些系统提供了 Linux 或 BSD 典型的包管理系统。每种都有自己的口味和包装，因此正确的选择将取决于您的口味和需求。

您可能会发现没有一个软件包系统能够提供您需要的所有程序。有些程序尚未移植到 OS X，因此不会出现在任何包系统。尽管如此，这些系统确实极大地扩展了 OS X 附带的功能，并将简化您从 Linux 的过渡。

OS X 命令行编译器现在默认构建 64 位可执行文件。

在 Leopard 及更早版本中，编译器默认构建 32 位可执行文件。这可能会以多种方式导致问题：也许您有无法重建但必须链接到的旧 32 位库，也许您仍在以 32 位模式运行系统，等等。

强制 32 位构建的一种方法是使用覆盖gcc构建系统中的默认值gcc-4.0，即旧的默认 32 位 Leopard 编译器。（gcc是 Snow Leopard 上默认 64 位的符号链接gcc-4.2。）使用基于 autoconf 的构建系统，这可以工作：

    $ ./configure CC=gcc-4.0 CXX=g++-4.0

CXX（如果程序包含 C++ 组件，则仅需要该位。）

另一种方法是传递-m32给编译器和链接器：

    $ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32

它需要更多的输入，但它可以让您从较新的 GCC 中获得 32 位构建。

动态链接有很大不同。

如果您是那种用手写ld命令的人，那么是时候改掉这个习惯了。您应该通过编译器链接程序和库，或者使用像libtool.这些解决了特定于平台的链接方案的细微差异，因此您可以节省脑力来学习无法通过便携式机制抽象出来的程序。

例如，您需要更新您的肌肉记忆，以便您通过打字otool -L someprogram而不是ldd someprogram找出someprogram链接到的库。

动态链接的另一个首先会让你绞尽脑汁的区别是，在 OS X 上，库的安装位置是被记录的在图书馆本身，链接器在链接时将其复制到可执行文件中。这意味着，如果您链接到已安装的库，/usr/local/lib但希望将其发送给与可执行文件位于同一目录中的用户，则需要在安装过程中说出如下内容：

    $ cp /usr/local/lib/libfoo.dylib .
    $ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
    $ make LDFLAGS=-L. relink

现在，上述大部分内容可能会因您的构建系统而异，因此仅将其作为示例，而不是配方。其作用是制作我们链接到的库的私有副本，将其共享库标识符从绝对路径更改为相对路径，这意味着“与可执行文件位于同一目录中”，然后根据此修改后的副本强制重建可执行文件图书馆的。

install_name_tool是这里的核心命令。如果您想将库安装在../lib与可执行文件相关的目录中，-id则需要使用参数@loader_path/../lib/libfoo.dylib。

乔·迪·波尔写道关于此的一篇好文章，有更多细节。

动态链接+第三方包可能会在早期引起头痛。

一旦您开始尝试使用未将库安装到标准位置的第三方包中的库，您很可能会尽早遇到动态链接问题。Mac端口例如，将库安装到/opt/local/lib, 而不是/usr/lib或中/usr/local/lib。当您遇到此问题时，解决该问题的一个好方法是将如下行添加到您的.bash_profile：

    # Tell the dynamic linker (dyld) where to find MacPorts package libs
    export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH

    # Add MacPorts header file install dirs to your gcc and g++ include paths
    export C_INCLUDE_PATH=/opt/local/include:$C_INCLUDE_PATH
    export CPLUS_INCLUDE_PATH=/opt/local/include:$CPLUS_INCLUDE_PATH

OS X 处理 CPU 兼容性问题的方式与 Linux 不同。

在 64 位 Linux 上，无论出于何种原因，您都必须支持 32 位，您最终会得到两个副本，例如需要采用两种格式的库，其中 64 位版本位于lib64与传统lib目录。

OS X 通过通用二进制概念以不同的方式解决了这个问题，它允许您将多个二进制文件放入一个文件中。目前，您可以拥有支持最多 4 种 CPU 类型的可执行文件：32 位和 64 位 PowerPC，以及 32 位和 64 位 Intel。

使用 Xcode 构建通用二进制文件很容易，但使用命令行工具则有点麻烦。这将为您提供基于 Autoconf 的构建系统的通用仅 Intel 构建：

    $ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
      LDFLAGS='-arch i386 -arch x86_64'

如果您需要 PowerPC 支持，请添加-arch ppc -arch ppc64到CFLAGS和。LDFLAGS

.o如果您不禁用依赖项跟踪，则最终只会针对一个平台进行构建，因为第一个平台的新建文件的存在表明make(1)它也不需要针对第二个平台进行构建。在上面的示例中，所有内容都必须构建两次；如果您仍然需要 PowerPC 支持，则对于完全通用的二进制文件，需要四次。

（更多信息在苹果技术说明 TN2137.)

默认情况下，OS X 上不安装开发人员工具。

在 Lion 出现之前，为您的系统获取正确的开发工具的最可靠的地方是操作系统光盘。它们是可选安装。

从操作系统光盘安装开发工具的好处是您知道这些工具将与操作系统一起使用。 Apple 就是 Apple，您必须拥有最新版本的操作系统才能运行最新的编译器，而且他们并不总是提供旧工具的下载，因此操作系统光盘通常是为给定的环境找到合适工具的最简单方法。开发或测试盒。

对于 Lion，他们试图取消安装介质，因此除非您购买昂贵的 USB 密钥版本，否则您将不得不从 App Store 下载 Xcode。

我建议您至少保留下载的任何 Xcode DMG 的几个版本。当 Lion 的继任者在一三年后问世时，您可能会发现自己无法在 Lion 测试 VM 上安装同期版本的 Xcode。提前计划，以防可用性问题和缺少操作系统介质导致无法获取旧版本的 Xcode。

Answer