在 OS X 中创建和使用动态库
我们有一个用 C++ 编写的 Windows 应用程序，我们正在尝试将其中一部分移植到 Mac OS X。我们的目标是将业务逻辑包装到一些库中，并在顶部为控制器和 GUI 构建一个 Cocoa 层。我们可能会有几个使用相同库的较小应用程序，因此我们的第一个想法是为 C++ 代码使用动态库（除非有更好的方法）。 然而，我们在实现这一目标方面遇到了一些问题。我们的动态库符合要求（至少看起来是这样），并且我们得到了一个 .dylib 文件，我们在应用程序中链接到该文件。问题是我们的应用程序根本找不到我们尝试包含的任何 .h 文件。 我们已经检查了 .h 文件是否正在导出，并检查了安装名称并确保该库位于正确的目录中。此外，我们遵循了 Apple 的创建和使用动态库指南，并没有发现我们遗漏了任何特殊步骤。
我的问题分为两部分：
- 是否有一些我们可能会遗漏的明显步骤，这有助于我们在其他任何事情之前尝试暴露接口（即 .h 文件）？
- 我们确实怀疑错误可能出在我们在这个项目中继承的蹩脚 C++ 代码中。例如，有很多逻辑（方法的实现）直接写在 .h 文件中，在某些情况下甚至根本没有相应的 .cpp 文件。因此 .h 文件不仅仅是接口的描述。这可能不是（严重的）问题，因为我们的应用程序甚至无法从库中找到 .h 文件，并且它们至少应该存在。 我们真的希望能够避免重写大量代码，因为需要移植的代码库非常大，而且（像往常一样）截止日期也很近。
PS：到目前为止，我们只在 Xcode 4.2 中工作，尚未尝试使用命令行工具。
We have a Windows application written in C++, part of which we are trying to port to Mac OS X. Our goal is to wrap the business logic into some libraries and build a Cocoa layer on top for the controller and the GUI. We will probably have several smaller apps using the same libraries so our first thought was to use dynamic libraries for the C++ code (unless there is a better way).
However, we are having some problems with achieving this. Our dynamic library complies fine (at least it looks like that) and we get a .dylib file which we link to in our app. The problem is that our app simply can't find any of the .h files we are trying to include.
We have already checked that the .h files are being exported as well as checked the install name and made sure that the library is located in the correct directory. Also, we have followed Apple's guide for creating and using dynamic libraries and found no special step we were missing.
My question here is in two parts:
- Is there some obvious step we might be missing which is instrumental in exposing the interface (i.e. the .h files) that we should try before anything else?
- We do suspect that the fault might be in the crappy C++ code we have inherited in this project. For instance, there is a lot of logic (implementation of methods) written directly in .h files and in some cases there isn't even a corresponding .cpp file at all. So the .h files aren't merely a description of the interface. This might not be the (solemn) problem as our app can't even find the .h files from the library and they should at be least present.
We really hope that we can avoid rewriting a lot of the code since the code base which needs to be ported is really large and (as usual) the deadline is close.
PS: We have so far only been working in Xcode 4.2 and have not tried with the command line tools yet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
选项 1
在这种情况下，我只需将包含标头的目录添加到 Xcode 中标头或库的发现路径中。根据布局的不同，某些方法会比其他方法更好。
通常，您将使用以下组合：
HEADER_SEARCH_PATHSLIBRARY_SEARCH_PATHSUSER_HEADER_SEARCH_PATHSFRAMEWORK_SEARCH_PATHS哪一个是正确的取决于您正在使用的库（例如，这些选项也会影响链接器）。定义发现路径时，可以添加后缀
**来表示递归搜索。这是理想的，因为您在保持 xc 项目与其解决方案同步方面会遇到更少的麻烦。
选项 2
有些人确实喜欢对其包含内容进行拖放支持...我不喜欢，但如果有太多杂乱无章的情况，您无法只做一些简单的事情，则可以采用这种方法添加搜索路径：将
如果标头名称存在冲突，那么它很快就会变得混乱，并且当您想要重用该库时需要几个小时才能重建。
Option 1
In this case, I would just add the directory containing the headers to the discovery paths for headers or libraries in Xcode. Depending on the layout, some approaches will be better than others.
Generally, you'll use some combination of:
HEADER_SEARCH_PATHSLIBRARY_SEARCH_PATHSUSER_HEADER_SEARCH_PATHSFRAMEWORK_SEARCH_PATHSWhich one is correct depends on the library you are using (e.g. these options can also affect the linker). When defining the discovery paths, you can add the suffix
**to denote a recursive search.This is ideal because you will have fewer troubles keeping your xc projects in sync with their vs solutions.
Option 2
Some people really like some drag and drop support for their includes... I don't, but this is the approach if there is so much disorganization that you can't just do something as simple as add a search path:
that gets messy quickly, and takes hours to reconstruct when you want to reuse the library if there are collisions in header names.