c++ - sistema - ¿Cuáles son las diferencias entre.so y.dylib en osx?

sistema operativo para mac

Question

.dylib es la extensión de biblioteca dinámica en OSX, pero nunca ha sido claro para mí cuando no puedo / no debo usar un objeto compartido unix tradicional .so.

Algunas de las preguntas que tengo:

• A nivel conceptual, ¿cuáles son las principales diferencias entre .so y .dylib?
• ¿Cuándo puedo / debo usar uno sobre el otro?
• Trucos y sugerencias de compilación (por ejemplo, el reemplazo de gcc -shared -fPIC, ya que eso no funciona en osx)

Answer 1

El archivo .so no es una extensión de archivo UNIX para la biblioteca compartida.

Simplemente pasa a ser uno común.

Ver la línea 3b en la página ArnaudRecipes sharedlib

Básicamente, .dylib es la extensión de archivo mac utilizada para indicar una biblioteca compartida.

Answer 2

La diferencia entre .dylib y .so en mac os x es cómo se compilan. Para archivos .so, usa -shared y para .dylib usa -dynamiclib. Tanto .so como .dylib son intercambiables como archivos de biblioteca dinámicos y tienen un tipo como DYLIB o BUNDLE. Aquí está la lectura de diferentes archivos que muestran esto.

libtriangle.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    17       1368   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS



libtriangle.so:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    17       1256   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS

triangle.so:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      BUNDLE    16       1696   NOUNDEFS DYLDLINK TWOLEVEL

La razón por la que ambos son equivalentes en Mac OS X es por compatibilidad con otros programas de sistema operativo UNIX que compilan con el tipo de archivo .so.

Notas de compilación: si compila un archivo .so o un archivo .dylib, necesita insertar la ruta correcta en la biblioteca dinámica durante el paso de enlace. Para ello, agregue -install_name y la ruta del archivo al comando de enlace. Si no lo hace, se encontrará con el problema que se ve en esta publicación: Mac Dynamic Library Craziness (Puede ser Fortran Only) .

Answer 3

Solo una observación que acabo de hacer mientras construyo código ingenuo en OSX con cmake:

cmake ... -DBUILD_SHARED_LIBS = OFF ...

crea archivos .so

mientras

cmake ... -DBUILD_SHARED_LIBS = ON ...

crea archivos .dynlib.

Quizás esto ayude a cualquiera.

Answer 4

El formato de archivo objeto Mach-O utilizado por Mac OS X para ejecutables y bibliotecas distingue entre bibliotecas compartidas y módulos cargados dinámicamente . Utilice otool -hv some_file para ver el tipo de archivo de some_file .

Las bibliotecas compartidas de Mach-O tienen el tipo de archivo MH_DYLIB y llevan la extensión .dylib. Se pueden vincular con los indicadores de vinculador estáticos habituales, por ejemplo, -lfoo para libfoo.dylib. Se pueden crear pasando el indicador -dynamiclib al compilador. ( -fPIC es el valor predeterminado y no es necesario especificarlo).

Los módulos cargables se denominan "paquetes" en Mach-O speak. Tienen el tipo de archivo MH_BUNDLE . Pueden llevar cualquier extensión; la extensión .bundle es recomendada por Apple, pero la mayoría del software portado usa .so por el bien de la compatibilidad. Normalmente, usará paquetes para complementos que amplíen una aplicación; en tales situaciones, el paquete se vinculará con el binario de la aplicación para obtener acceso a la API exportada de la aplicación. Se pueden crear pasando el indicador de -bundle al compilador.

Tanto dylibs como bundles pueden cargarse dinámicamente utilizando las API dl (por ejemplo, dlclose , dlclose ). No es posible vincular paquetes como si fueran bibliotecas compartidas. Sin embargo, es posible que un paquete esté vinculado a bibliotecas compartidas reales; esos se cargarán automáticamente cuando se cargue el paquete.

Históricamente, las diferencias fueron más significativas. En Mac OS X 10.0, no había forma de cargar dinámicamente las bibliotecas. Un conjunto de dyld API (por ejemplo, NSCreateObjectFileImageFromFile , NSLinkModule ) se introdujeron con 10.1 para cargar y descargar paquetes, pero no funcionaron para dylibs. Se dlopen biblioteca de compatibilidad dlopen que funcionaba con paquetes en 10.3; en 10.4, dlopen fue reescrito para ser una parte nativa de dyld y se agregó compatibilidad para cargar (pero no descargar) dylibs. Finalmente, 10.5 agregó soporte para usar dlclose con dylibs y desactivó las API dyld.

En sistemas ELF como Linux, ambos usan el mismo formato de archivo ; cualquier fragmento de código compartido se puede usar como biblioteca y para carga dinámica.

Finalmente, tenga en cuenta que en Mac OS X, "bundle" también puede referirse a directorios con una estructura estandarizada que contiene código ejecutable y los recursos utilizados por ese código. Existe una superposición conceptual (particularmente con los "paquetes cargables", como los complementos, que generalmente contienen código ejecutable en forma de un paquete Mach-O), pero no se deben confundir con los paquetes Mach-O mencionados anteriormente.

Referencias adicionales:

• Fink Porting Guide , la base de esta respuesta (aunque bastante desactualizada, ya que fue escrita para Mac OS X 10.3).
• ld(1) y dlopen(3)
• Temas de programación de biblioteca dinámica
• Temas de programación Mach-O