¿Cómo creo un marco de trabajo con archivos dylib en Xcode 4

macos frameworks

Question

He creado un nuevo marco de cocoa en Xcode, eliminé todas las bibliotecas y archivos que incluye al principio, excepto los archivos de soporte.

Tengo 2 archivos:

add.h
#ifndef add_add_h
#define add_add_h
void add(void);
#endif

y

add.c
#include <stdio.h>
#include "add.h"
void add(void)
{
printf("adfding");
}

en las fases de compilación agrego add.c para compilar fuentes y add.h para compilar encabezados públicos. El proyecto se compila sin problemas, pero en el marco no hay un archivo dylib y cuando arrastro y suelto el marco a otro proyecto, dice que no se pudo encontrar el archivo dylib.

dyld: Library not loaded: @rpath/add.framework/Versions/A/add
Referenced from: /Users/vjoukov/Desktop/Projects/test/build/Debug/test.app/Contents/MacOS/test
Reason: image not found

¿Cómo puedo hacer un marco simple y mantener archivos dylib dentro de él?

Answer 1

Creo que estás malinterpretando el mensaje de error.

Un .framework funciona como una biblioteca dinámica, pero no habrá ningún archivo de objeto cargable Mach-O con una extensión de nombre de archivo .dylib real dentro de la carpeta .framework.

Hay un par de razones por las que podría estar recibiendo ese mensaje de error de dyld , el cargador de biblioteca de enlace dinámico, en tiempo de ejecución. La primera es que se olvidó de copiar el .frameworks en el paquete de aplicaciones construidas durante el proceso de construcción. Si bien se pueden copiar en cualquier ubicación dentro del paquete de aplicaciones, el lugar tradicional se encuentra en AppName.app/Contents/Frameworks/. Si aún no lo ha hecho, elija Proyecto> Nueva fase de compilación> Nueva fase de compilación de archivos de copia. Cambie la ventana emergente Destino a Marcos como en la imagen de abajo.

Luego arrastrará el icono del marco a la carpeta para que se copie durante el proceso de construcción.

La segunda y más probable razón por la que no se puede encontrar el marco en tiempo de ejecución es que no ha especificado ninguna ruta de búsqueda de ruta de ejecución para su ejecutable principal. (Esto es necesario porque, como vimos en su mensaje de error, su marco se creó utilizando el nuevo nombre de instalación @rpath/ style ( @rpath/add.framework/Versions/A/add ) en lugar del antiguo @executable_path/ o @loader_path/ estilos).

Siempre que copie los marcos personalizados a la ubicación mencionada anteriormente, agregará una entrada de ruta de acceso de búsqueda de @loader_path/../Frameworks de @loader_path/../Frameworks , como se muestra en la siguiente imagen:

El siguiente extracto que explica cómo se encuentran las bibliotecas dinámicas en tiempo de ejecución es de la página del dyld de dyld :

BIBLIOTECA DINAMICA

A diferencia de muchos otros sistemas operativos, Darwin no localiza bibliotecas dinámicas dependientes a través de su nombre de archivo de hoja. En su lugar, se utiliza la ruta completa a cada dylib (por ejemplo, /usr/lib/libSystem.B.dylib ). Pero hay ocasiones en que un camino completo no es apropiado; por ejemplo, puede querer que sus archivos binarios sean instalables en cualquier parte del disco. Para admitir eso, hay tres variables @xxx/ que se pueden usar como un prefijo de ruta. En tiempo de ejecución, dyld sustituye una ruta generada dinámicamente para @xxx/ prefix.

@executable_path/

Esta variable se reemplaza con la ruta al directorio que contiene el ejecutable principal del proceso. Esto es útil para cargar dylibs / frameworks incrustados en un directorio .app. Si el archivo ejecutable principal está en /some/path/My.app/Contents/MacOS/My y un archivo dylib de marco está en
/some/path/My.app/Contents/Frameworks/Foo.framework/Versions/A/Foo , entonces la ruta de carga del framework podría codificarse como @executable_path/../Frameworks/Foo.framework/Versions/A/Foo and El directorio .app podría moverse en el sistema de archivos y dyld todavía podrá cargar el marco incorporado.

@loader_path/

Esta variable se reemplaza con la ruta al directorio que contiene el binario mach-o que contiene el comando de carga usando @loader_path . Por lo tanto, en cada binario, @loader_path resuelve en una ruta diferente, mientras que @executable_path siempre se resuelve en la misma ruta. @loader_path es útil como ruta de carga para un framework / dylib incrustado en un complemento, si la ubicación final del sistema de archivos del complemento no se conoce (por lo tanto, las rutas absolutas no se pueden usar) o si el complemento es usado por múltiples aplicaciones (por @executable_path que no se puede usar @executable_path ). Si el archivo de plug-in mach-o está en /some/path/Myfilter.plugin/Contents/MacOS/Myfilter y un archivo dylib de marco está en /some/path/Myfilter.plugin/Contents/Frameworks/Foo.framework/Versions/A/Foo , entonces la ruta de carga del marco podría codificarse como @loader_path/../Frameworks/Foo.framework/Versions/A/Foo y el directorio Myfilter.plugin podría moverse en el sistema de archivos y dyld seguirá siendo capaz de cargar el marco incrustado.

@rpath/

Dyld mantiene una pila actual de rutas llamada la lista de rutas de ejecución. Cuando se encuentra @rpath , se sustituye por cada ruta en la lista de rutas de ejecución hasta que se encuentre un dylib cargable si se encuentra. La pila de la ruta de ejecución se LC_RPATH partir de los comandos de carga LC_RPATH en la cadena de dependencia que conducen a la carga actual de dylib. Puede agregar un LC_RPATH carga LC_RPATH a una imagen con la opción -rpath a ld (1). Incluso puede agregar una LC_RPATH comando de carga LC_RPATH que comienza con @loader_path/ , y empujará una ruta en la pila de ruta de ejecución que se relaciona con la imagen que contiene el LC_RPATH . El uso de @rpath es más útil cuando tiene una compleja estructura de directorios de programas y dylibs que se pueden instalar en cualquier lugar, pero mantienen sus posiciones relativas. Este escenario podría implementarse utilizando @loader_path , pero cada cliente de un dylib podría necesitar una ruta de carga diferente porque su posición relativa en el sistema de archivos es diferente. El uso de @rpath introduce un nivel de direccionamiento indirecto que simplifica las cosas. Usted elige una ubicación en su estructura de directorio como un punto de anclaje. Cada dylib luego obtiene una ruta de instalación que comienza con @rpath y es la ruta al dylib en relación con el punto de anclaje. Cada ejecutable principal está vinculado con -rpath @loader_path/zzz , donde zzz es la ruta desde el ejecutable al punto de anclaje. En el tiempo de ejecución, dyld establece que la ruta de ejecución sea el punto de anclaje, luego cada dylib se encuentra en relación con el punto de anclaje.