2011-04-21 14 views
6

Estoy intentando escribir un generador QuickLook. Para esto, necesito vincularme con un marco que creé. Sin embargo, tan pronto como me enlace contra dicho marco, qlmanage se niega a cargar mi complemento diciéndome:Vinculación de marcos en los complementos de QuickLook

[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. 

He leído todos los tutoriales relevantes sobre la vinculación, los marcos y QuickLook pero no encontró respuesta.

cosas que he descubierto/descartado hasta ahora

  • Arquitectura: cuando se incluye el Marco como binario de 32 bits, la totalidad de los errores del proceso de vinculación, por lo que este no parece ser el problema.
  • He verificado que el Framework se copia en el paquete del complemento bajo Contents/Frameworks.
  • ruta de instalación del marco se establece en @executable_path/../Frameworks

Además, al utilizar el marco de otra aplicación, todo va bien. La única explicación posible que puedo comprender es la siguiente: Al ejecutar qlmanage, el @executable_path en realidad apunta a ese binario y, por lo tanto, mi marco de trabajo nunca se encuentra. Si este es el caso, ¿cómo debo configurar la ruta de instalación para que aún permita una ubicación relativa al complemento? No quiero instalar mi marco globalmente.

EDITAR

otool -L en la construcción QuickLook Plugin se obtiene la siguiente:

/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 en mi marco produce esto:

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

El Marco no requiere basura colección.

Respuesta

7

@executable_path se resuelve de la imagen ejecutable principal del proceso. Ese sería el daemon quicklook, no su complemento. Deberías usar @loader_path en su lugar.

Aquí hay un blog post que cubre esto.

+0

Gracias. De hecho, había leído sobre algunas de esas variables (incluyendo '@ loader_path' y' @ rpath') pero no le di mucha importancia. –

+1

... idealmente cambie a '@ rpath' como también lo sugiere http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/ – Jay

1

No dice si la aplicación en la que utilizó su marco requería recolección de basura. Tampoco dices si tu marco lo requiere. Es posible que esté intentando compilar su generador de búsqueda rápida utilizando la recolección de basura. Pero, "los generadores Quick Look no se compilan con la recolección de basura", de acuerdo con Nicholas Riley's reply to this post. Esto solo puede explicar por qué, como dices, "todo el proceso de vinculación falla", si es eso lo que intentas.

Al no estar familiarizado con su framework, no tengo idea de cuán involucrado sería el proceso para eliminar la dependencia de la recolección de basura (si es que así es), pero su framework puede requerir una nueva versión para ser utilizado en un Quick Mira generador.

+0

No, ni el marco ni la aplicación lo probé con GC usado. Por supuesto, he leído toda la discusión relevante sobre SO (y, específicamente, la que usted ha vinculado). Dice que habría filtraciones, pero las filtraciones no son mi problema (al menos no ahora).Además, mi comentario de que "todo el proceso de vinculación falla" solo se aplica (como ya he dicho) "cuando se incluye el Framework como binario de 32 bits", por lo que no veo cómo debería ser relevante para la cuestión de la basura. colección: cuando las arquitecturas de compilación de plugin y framework * coinciden *, el proceso de enlace, por supuesto, pasa muy bien. –

Cuestiones relacionadas