将框架链接到 QuickLook 插件中

发布于 2024-11-02 22:25:12 字数 1951 浏览 5 评论 0原文

我正在尝试编写一个 QuickLook 生成器。为此,我需要链接到我创建的框架。但是,一旦我链接到所述框架,qlmanage 就会拒绝加载我的插件,并告诉我:

[ERROR] Can't load plug-in at /path/to/my-ql.qlgenerator: The bundle “my-ql” couldn’t be loaded because it is damaged or missing necessary resources.

我已阅读有关链接、框架和 QuickLook 的所有相关教程,但没有找到答案。

到目前为止我发现/排除的事情

  • 架构:当将框架包含为 32 位二进制时,整个链接过程会出错,因此这似乎不是问题。
  • 我已经验证框架已复制到 Contents/Frameworks 下的插件包中。
  • 框架的安装路径设置为 @executable_path/../Frameworks

此外,在另一个应用程序中使用该框架时,一切顺利。我能理解的唯一可能的解释如下:执行 qlmanage 时,@executable_path 实际上指向该二进制文件,因此我的框架从未找到。如果是这种情况,我必须如何设置安装路径才能仍然允许相对于插件的位置?我不想在全球范围内安装我的框架。

编辑

otool -L 在构建的 QuickLook 插件上产生以下结果:

/System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook (compatibility version 1.0.0, current version 327.4.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
@executable_path/../Frameworks/PESHandler.framework/Versions/A/PESHandler (compatibility version 1.0.0, current version 1.0.0) <== *this is my framework*
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)

otool -D 在我的框架上产生以下结果:

@executable_path/../Frameworks/PESHandler.framework/Versions/A/PESHandler

框架不需要垃圾收集。

I am trying to write a QuickLook generator. For this, I need to link against a framework I created. However, as soon as I link against said framework, qlmanage refuses to load my plugin by telling me:

[ERROR] Can't load plug-in at /path/to/my-ql.qlgenerator: The bundle “my-ql” couldn’t be loaded because it is damaged or missing necessary resources.

I have read all the relevant tutorials on Linking, Frameworks and QuickLook but found no answer.

Things I have found out/ruled out so far

  • Architecture: when including the Framework as 32-bit binary, the entire linking process faults, so this does not seem to be the problem.
  • I have verified that the Framework gets copied into the plugin’s bundle under Contents/Frameworks.
  • The framework’s install path is set to @executable_path/../Frameworks

Also, when using the framework in another application, everything goes well. The only possible explanation I can fathom is as follows: When executing qlmanage, the @executable_path actually points to that binary and so my framework is never found. If this is the case, how must I set the install path to still allow a location relative to the plugin? I don’t want to install my framework globally.

EDIT

otool -L on the built QuickLook Plugin yields the following:

/System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook (compatibility version 1.0.0, current version 327.4.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
@executable_path/../Frameworks/PESHandler.framework/Versions/A/PESHandler (compatibility version 1.0.0, current version 1.0.0) <== *this is my framework*
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)

otool -D on my framework yields this:

@executable_path/../Frameworks/PESHandler.framework/Versions/A/PESHandler

The Framework does not require garbage collection.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

习惯成性 2024-11-09 22:25:12

@executable_path 解析进程的主可执行映像。那将是 Quicklook 守护进程,而不是您的插件。您应该改用@loader_path。

这是一篇博客文章 涵盖这一点。

@executable_path resolves against the main executable image for the process. That would be the quicklook daemon, not your plug-in. You should use @loader_path instead.

Here's a blog post covering this.

ゝ偶尔ゞ 2024-11-09 22:25:12

您没有说明使用框架的应用程序是否需要垃圾收集。你也没有说你的框架是否需要它。您可能正在尝试使用垃圾收集来编译 Quick Look 生成器。但是,根据尼古拉斯·莱利对此帖子的回复。仅此一点就可以解释为什么,正如您所说,“整个链接过程出现故障”,如果这确实是您正在尝试的。

由于不熟悉您的框架,我不知道消除对垃圾收集的依赖的过程会涉及多少(如果再次是这种情况),但您的框架可能需要重新设计才能在快速查看生成器中使用。

You don't say if the application in which you used your framework required garbage collection. Nor do you say if your framework requires it. You may be attempting to compile your Quick Look generator using garbage collection. But, "Quick Look generators don't get compiled with garbage collection on," according to Nicholas Riley's reply to this post. This alone may explain why, as you say, "the entire linking process faults," if indeed that's what you're attempting.

Lacking familiarity with your framework, I have no idea how involved the process would be to eliminate reliance on garbage collection (if, again, that's the case), but your framework may require reworking in order to be used in a Quick Look generator.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文