Mac: ¿Cómo exportar símbolos desde un ejecutable?

Question

Estoy escribiendo un ejecutable que usa dlopen() (LoadLibrary() en Windows) para cargar dinámicamente una biblioteca compartida. La biblioteca compartida usa símbolos del ejecutable.

En Windows esto es posible. Los ejecutables pueden exportar símbolos: los archivos declspec (dllexport) y .def funcionan. El enlazador, al crear el .exe, también crea el archivo .lib (la "biblioteca de importación"), por lo que el DLL solo necesita vincularlo con ese .lib.

En Linux, esto también es posible. Paso -Wl, -export_dynamic cuando construyo el ejecutable para que exporte sus símbolos.

En Mac OS X, en lugar ... -Wl, -export_dynamic no funciona, pero hay -Wl, -exported_symbols_list, <filename> donde <filename> es una lista de símbolos para exportar (una especie de una versión más simple de un archivo .def). Pero luego, construir la biblioteca compartida no es tan fácil: el enlazador se queja de los símbolos no resueltos.

Probé un truco: cambié el nombre del ejecutable a lib <executable> .dylib y, al vincular la biblioteca compartida, pasé -l <executable>. Pero da el error "no se puede vincular con un ejecutable principal".

El problema general es que las bibliotecas compartidas de Linux pueden tener símbolos no resueltos, mientras que Windows y Mac OS X no lo permiten. Pero Windows tiene "bibliotecas de importación" para resolver símbolos contra dependencias, y aparentemente Mac OS X no ...

¿Cómo se puede resolver esto en Mac OS X? ¿Hay un equivalente de una "biblioteca de importación" (la biblioteca de stub creada por el enlazador de Windows al crear un .dll, entonces, si algún módulo necesita vincular dinámicamente al .dll, está vinculado a la "biblioteca de importación")? ¿O alguna otra solución?

Answer 1

El intérprete independiente de Lua admite la carga dinámica (a través de dlopen) de bibliotecas compartidas que utilizan símbolos del ejecutable (la API de Lua). No se utiliza ninguna bandera de enlace especial al construirlo. Las bibliotecas compartidas se construyen con este encantamiento:

env MACOSX_DEPLOYMENT_TARGET=10.3 gcc -bundle -undefined dynamic_lookup -o random.so lrandom.o 

Answer 2

Gracias, su respuesta estimuló el deseo de investigar la diferencia entre los haces y dylibs. Y la página del manual de LD menciona una opción llamada -bundle_loader

-bundle_loader ejecutable
Especifica el ejecutable que se carga el archivo de salida haz siendo vinculado. Los símbolos no definidos del paquete se comprueban con el ejecutable especificado como si fuera un de las bibliotecas dinámicas con las que se enlazó el paquete.

(tenga en cuenta que -bundle_loader falla cuando la construcción de una dylib, sólo funciona con paquetes) línea de comandos para el viejo

cc -shared -o <output>.so <input>.c 

fue convertido en

cc -bundle -bundle_loader <executable> -o <output>.so <input>.c 

y el haz de salida resolvió sus símbolos indefinidos contra los del ejecutable.