我使用过 Ubuntu/Fedora/Red Hat/Suse 但根本没有使用过 OS X。如果我必须定期开始使用 OS X，我应该注意什么？
我使用的工具是 GNU 工具链、C++/Boost 等。
War*_*ung 54
几年前我做了同样的举动。以下是我遇到的事情：
您的普通桌面 Linux 拥有比 OS X 更丰富的用户空间。
您可能会错过与我不同的工具，因此没有必要对替换建议进行具体说明。
相反，只需首先安装Fink、MacPorts或Homebrew。这些系统提供了典型的 Linux 或 BSD 包管理系统。每个都有自己的口味和套餐，因此正确的选择将基于您的口味和需求。
您可能会发现没有一个软件包系统会拥有您需要的所有程序。有些程序尚未移植到 OS X，因此它们不会出现在任何软件包系统中。尽管如此，这些系统确实极大地扩展了 OS X 附带的功能，并将简化您从 Linux 的过渡。
OS X 命令行编译器现在默认构建 64 位可执行文件。
在 Leopard 及更早版本中，编译器默认构建 32 位可执行文件。这可能会以多种方式导致问题：也许您有无法重建但必须链接到的旧 32 位库，也许您仍在以 32 位模式运行系统，等等。
强制进行 32 位构建的一种方法是使用 覆盖gcc构建系统中的默认值gcc-4.0，即旧的 32 位默认 Leopard 编译器。（gcc是gcc-4.2Snow Leopard 上默认 64 位的符号链接。）使用基于 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。
动态链接+第三方包可能会在早期引起头痛。
一旦您开始尝试使用未将库安装到标准位置的第三方包中的库，您很可能会在早期遇到动态链接问题。MacPorts 会这样做，例如，将库安装到/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'
添加-arch ppc -arch ppc64到CFLAGS和LDFLAGS如果您需要 PowerPC 支持。
如果您不禁用依赖项跟踪，则最终只会为一个平台构建，因为第一个平台的新建.o文件的存在使您相信make(1)它也不需要为第二个平台构建。在上面的例子中，一切都必须构建两次；如果您仍然需要 PowerPC 支持，则对于完全通用的二进制文件是四次。
（Apple 技术说明 TN2137 中的更多信息。）
默认情况下，OS X 上未安装开发人员工具。
在 Lion 之前，为您的系统获取正确开发工具的最可靠的地方是在操作系统光盘上。它们是可选安装。
从 OS 光盘安装开发工具的好处是您知道这些工具可以与 OS 一起使用。Apple 是 Apple，您必须拥有最新版本的操作系统才能运行最新的编译器，而且他们并不总是提供旧工具的下载，因此操作系统光盘通常是为给定的工具找到合适工具的最简单方法开发或测试盒。
对于 Lion，他们试图取消安装媒体，因此除非您购买昂贵的 USB 密钥版本，否则您必须从 App Store 下载 Xcode。
我建议您至少保留下载的任何 Xcode DMG 的几个版本。当 Lion 的继任者在一三年后问世时，您可能会发现自己无法在 Lion 测试 VM 上安装同期版本的 Xcode。提前计划，以防可用性问题和操作系统媒体的缺乏导致旧版本的 Xcode 无法获得。
gab*_*be. 31
巨大的陷阱——Mac OS 文件系统不区分大小写。
尽管 Fink 和 MacPorts 是在 OS X 上获取 unix 软件包的传统方法，但我建议您查看一个名为的新工具，它对brew我来说效果更好，对我的系统的干扰更少，并且更易于使用。它基本上只是下载 tarball 并安装到 /usr/local，但它可以很好地自动化整个过程。
http://mxcl.github.com/homebrew/