.dylib动态链接库可以打包成可执行文件吗？
（是的，我知道 dylib 的全部意义在于它动态加载，但我正在尝试创建一个独立的包。）
我有一个从命令行构建的可执行文件（在 macOS Lion 上，如果这很重要）。我将可执行文件交付给朋友，但他无法运行它，因为他没有安装库。他宁愿不安装这些库，所以现在我正在尝试创建一个包含原始可执行文件以及所有所需库的包。
我习惯在 Xcode IDE 中工作，并且不太熟悉 make 和其他命令行构建工具及其选项。 （我按照网上的很好的说明构建了这个工具。）因此，明确的说明会很有帮助。
谢谢！
(Yes, I understand that the whole point of dylib is that it loads dynamically, but I’m trying to create a self-contained package.)
I’ve got an executable that I built from the command line (on macOS Lion, if it matters). I delivered the executable to a friend, but he can’t run it because he doesn’t have the libraries installed. He’d rather not install the libraries, so now I’m trying to create a package that includes the original executable, plus all the needed libs.
I’m used to working in the Xcode IDE and am not very familiar with make and other command-line build tools and their options. (I built this tool following very good instructions from the web.) Hence, explicit instructions would be helpful.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能直接将 dylib 放入可执行文件中。 （这几乎就是捆绑包的发明目的，但这对您使用命令行工具没有帮助。）
您可以将每个 dylib 重建为静态（
.a）库，在这种情况下，所有您的可执行文件所需的代码将被复制到可执行文件中，并且您不需要使用它分发任何内容。如果您拥有库的源代码，这通常非常容易，但如果不确切知道如何构建事物，就很难告诉您要更改哪些内容。关于静态链接需要记住的一件事是它会影响不同许可证一起使用的方式。特别是，如果您使用的任何库都是 LGPL 许可的，则静态链接它们会产生动态链接不会产生的后果。有关更多详细信息，请参阅此问题（以及答案上的链接），但实际上，您不应该相信 Stack Overflow 上关于许可证的法律建议的答案。不管怎样，这对于OP的“我想构建一个程序并将其交给我的朋友”来说可能不是问题，但对于稍后阅读这个问题的其他人来说，这可能是问题。
如果静态链接不可能或不可取，那么您所需要做的就是将可执行文件和 dylib 打包在一起，然后将它们放到您朋友的计算机上。由于他显然不想运行安装程序，这意味着 tarball 或 ZIP 文件。
唯一棘手的部分是确保可执行文件知道在哪里可以找到 dylib。除非每个 dylib 都在 dyld 搜索路径中（有关更多详细信息，请参阅 dyld 的联机帮助页，但如果您不想安装任何内容，它不会对您有帮助），或者在完全相同的路径中如果它位于链接时的位置，则运行可执行文件将失败，并出现来自
dyld的“未找到图像”错误。幸运的是，“完全相同的地方”可以意味着像@executable_path/libfoo.dylib这样的神奇路径，这意味着“与
myexe在同一目录中”，而不是绝对路径例如/opt/local/lib/libfoo.dylib或相对路径，例如../../foo/build/Release/libfoo.dylib。 （请注意，正常的相对路径是相对于当前工作目录的，而不是相对于可执行文件或捆绑包目录。）您可以通过执行以下操作来查看 myexe 正在查找的位置：
@executable_path中未查找的任何内容（除了/lib和/usr/lib中的内容（它是操作系统的一部分，不需要分发），您可以像这样修复它：现在，你只需要正确复制所有这些dylibs在
myexe旁边，将其压缩，然后将其交给您的朋友，他只需解压它并运行该 exe。You can’t directly put a dylib inside an executable. (That’s pretty much what bundles were invented for—but that doesn’t help you with command-line tools.)
You can rebuild each dylib as a static (
.a) library, in which case all the code your executable needs will be copied into the executable, and you don’t need to distribute anything with it. If you’ve got the source to the libraries, this is usually very easy—but without knowing exactly how you’re building things, it’s hard to tell you what to change.One thing to keep in mind with static linking is that it affects how different licenses play together. In particular, if any of the libraries you’re using are LGPL-licensed, static-linking them has consequences that dynamic linking doesn’t. See this question (and the links on the answer) for more details, but really, you shouldn’t trust answers on Stack Overflow for legal advice on licenses. Anyway, that probably isn’t an issue for the OP’s “I want to build a program and give it to my friend”, but for others reading this question later, it might be.
If static linking isn’t possible or desirable, all you need to do is package up the executable and dylibs together and get them onto your friend’s machine. Since he apparently doesn’t want to run an installer, that means a tarball or a ZIP file.
The only tricky part is making sure the executable knows where to find the dylibs. Unless each dylib is either in the dyld search path (see the manpage for
dyldfor more details, but it’s not going to help you if you don’t want to install anything), or in the exact same place it was at the time you linked it, running the executable will fail with an “image not found” error fromdyld.Fortunately, “exact same place” can mean a magic path like
@executable_path/libfoo.dylib, which means “in the same directory asmyexe”, rather than an absolute path like/opt/local/lib/libfoo.dylibor a relative path like../../foo/build/Release/libfoo.dylib. (Note that normal relative paths are relative to the current working directory, not the executable or bundle directory.)You can see where myexe is looking by doing this:
Anything that’s not looking in
@executable_path(except for stuff in/liband/usr/lib, which is a part of the OS and doesn’t need to be distributed), you can fix it like so:Now, you just need to copy all those dylibs right next to
myexe, tar it up, and give it to your friend, and he can just untar it and run the exe.在 macOS 上，dylib 通常存储在“/usr/local/”中。默认情况下，所有应用程序都会在“/usr/local/”中查找任何所需的dylib。
选项 1 是将 dylib 放置在您朋友的计算机“/usr/local/”中。
选项 2，将 dylib 放在与可执行文件相同的目录中。
选项 3，修复应用程序或 dylib 中的路径。 在 /usr/lib 中查找 XCode dylib 将会很有用。您可以使用此选项将 dylib 打包到您选择的位置，即应用程序包内部和外部。
On macOS the dylibs are normally stored at "/usr/local/". By default all applications looks for any required dylibs in "/usr/local/".
Option 1 is to place the dylibs in your friends machines "/usr/local/".
Option 2, place the dylibs in the same directory as your executable.
Option 3, Fix the path in the application or the dylib. XCode dylib looking in /usr/lib will be useful. You can use this option to package the dylibs to the location of your choice i.e. both inside and outside the application package.