c++ - tiempo - steam carpeta compartida bloqueada
¿Cuál es el trato con los símbolos indefinidos en una biblioteca compartida o dylib? (2)
Tengo un Makefile para Linux que estoy trasladando a Darwin. El archivo makefile toma un montón de archivos .o y los enlaza en un objeto compartido .so. Bien, entonces pensé (¿estoy equivocado con esto?) Que el mejor análogo para esto en Darwin es el dylib. Así que cambié la bandera -shared a -dynamiclib.
Ahora el código que estoy enlazando en el dylib depende de muchas bibliotecas externas. Cuando trato de construir el dylib, recibo errores que dicen que hay referencias no definidas. Pero el Makefile de Linux no especifica ninguna de las opciones -lwhatever o -L / path / whatever en el paso de compilación que crea el archivo .so. Hm ¿Esto se debe a que cuando crea un archivo ELF .so, de forma predeterminada deja las referencias externas sin resolver, y luego cuando se carga la biblioteca compartida, recursivamente carga bibliotecas compartidas de las que depende la biblioteca compartida que está cargando? ¿No sería el caso de que si la biblioteca compartida dependiera de un archivo .a o .o, TENDRÍAS que vincularlos de forma estática a la biblioteca compartida, de lo contrario no podrías vincular en tiempo de ejecución? ¿Cómo puede evitar tener referencias no definidas en una biblioteca que se carga en tiempo de ejecución, a menos que las referencias también sean bibliotecas que se pueden cargar dinámicamente?
De todos modos así que si especifico
-undefined suppress -flat_namespace
no requiere que agregue esas opciones -l y -L al crear la biblioteca compartida. Pero todavía no entiendo cómo esto puede funcionar en última instancia.
Utilice libtool .
libtool -dynamic -multiply_defined suppress -install_name `basename ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib` -o ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib ../../../../rlp/lib/universal-darwin9-gcc40/libbtd.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttrie.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtkey.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtunit.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtutilities.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtopts.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxcode.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtprops.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxml.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake3.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake5.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtac.a -lstdc++.6 -lgcc_s.10.4 ../../../../build_system/lib/universal-darwin9-gcc40/libgcc.a -lSystem -lSystemStubs`
Este hilo también trata este tema. Creo que el punto clave es que para obtener el comportamiento de enlace similar a Linux, es necesario especificar el indicador "-undefined dynamic_lookup". De forma predeterminada, el enlazador de Darwin emite un error si hay referencias no definidas en una biblioteca dinámica. También puede usar -U para establecer este comportamiento por símbolo. Ver ''man ld'' para referencia.