在 OS X 中创建和使用动态库答案

【问题标题】：Creating and using dynamic libraries in OS X在 OS X 中创建和使用动态库
【发布时间】：2011-12-15 12:24:18
【问题描述】：

我们有一个用 C++ 编写的 Windows 应用程序，我们正在尝试将其中的一部分移植到 Mac OS X。我们的目标是将业务逻辑封装到一些库中，并在顶部为控制器和 GUI 构建一个 Cocoa 层。我们可能会有几个较小的应用程序使用相同的库，所以我们的第一个想法是为 C++ 代码使用动态库（除非有更好的方法）。但是，我们在实现这一目标时遇到了一些问题。我们的动态库符合要求（至少看起来是这样），并且我们得到了一个 .dylib 文件，我们在我们的应用程序中链接到该文件。问题是我们的应用程序根本找不到我们试图包含的任何 .h 文件。我们已经检查了 .h 文件是否正在导出，并检查了安装名称并确保库位于正确的目录中。此外，我们遵循了 Apple 的创建和使用动态库的指南，没有发现我们遗漏的任何特殊步骤。

我的问题分为两部分：

是否有一些我们可能遗漏的明显步骤有助于公开我们应该先尝试的接口（即 .h 文件）？
我们确实怀疑问题可能出在我们在此项目中继承的糟糕 C++ 代码中。例如，有很多逻辑（方法的实现）直接写在 .h 文件中，在某些情况下甚至根本没有对应的 .cpp 文件。所以 .h 文件不仅仅是接口的描述。这可能不是（严重的）问题，因为我们的应用程序甚至无法从库中找到 .h 文件，它们至少应该存在。我们真的希望我们可以避免重写大量代码，因为需要移植的代码库非常大，而且（和往常一样）截止日期很近。

PS：到目前为止，我们只在 Xcode 4.2 中工作，还没有尝试使用命令行工具。

【问题讨论】：

确保您已在项目/目标的构建设置中指定库的包含文件的路径：标头搜索路径或用户标头搜索路径。
确保头文件在您期望的位置（在文件系统中）
我们实际上是出于纯粹的绝望而这样做的，而且有点奏效。但这真的有必要吗？我的意思是，这意味着当您分发库时，您还必须分发头文件。所以 .dylib 与 Windows 中完全自包含的 .dll 文件的工作方式不同？
在这种情况下，我们是否应该改为研究框架（如果我理解正确，它也会打包头文件）。当我们想在多个应用中使用它时会产生什么影响？
@NobleK 您不需要在您的应用程序中发送头文件。另一方面，如果您将库交付给其他开发人员使用，那么是的，您也需要交付头文件，并且您可以为此使用框架。

标签： c++ xcode macos dylib dynamic-library

【解决方案1】：

选项 1

在这种情况下，我只需将包含标头的目录添加到 Xcode 中标头或库的发现路径中。根据布局，某些方法会比其他方法更好。

通常，您会使用以下组合：

HEADER_SEARCH_PATHS
LIBRARY_SEARCH_PATHS
USER_HEADER_SEARCH_PATHS
或FRAMEWORK_SEARCH_PATHS

哪个是正确的取决于您使用的库（例如，这些选项也会影响链接器）。定义发现路径时，可以添加后缀**，表示递归搜索。

这是理想的选择，因为让您的 xc 项目与他们的 vs 解决方案保持同步的麻烦更少。

选项 2

有些人真的很喜欢对其包含的拖放支持...我不喜欢，但如果存在如此多的混乱以至于您不能只做像添加搜索路径这样简单的事情，这就是这种方法：

将您需要的标头添加到项目中
将这些标头添加到目标的复制标头构建阶段
重复直到构建完成，并在合并/拉取更新时为损坏做好准备。

如果标题名称发生冲突，当您想要重用库时，它会很快变得混乱，并且需要数小时才能重建。

【讨论】：

感谢您在此处和上面的评论中的回答。