Tengo un Makefile para Linux que transfiero a Darwin. El archivo MAKE toma un grupo de archivos .O y los vincula en un objeto compartido .so. De acuerdo, entonces pensé (¿me equivoco sobre esto?) Que el mejor análogo para esto en Darwin es el dylib. Así que cambié el indicador -shared por -dynamiclib.¿Cuál es el problema con los símbolos indefinidos en una biblioteca compartida o dylib?
Ahora el código que estoy uniendo en el dylib depende de muchas bibliotecas externas. Cuando intento construir el dylib, recibo errores que dicen que hay referencias indefinidas. Pero Linux Makefile 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 al crear un archivo .so ELF, de forma predeterminada deja sin resolver las referencias externas y luego cuando se carga la biblioteca compartida, recursivamente carga las bibliotecas compartidas de las que depende la biblioteca compartida que está cargando? ¿No sería el caso que si la biblioteca compartida depende de un archivo .a o .o, TENDRÍA que vincular estáticamente a la biblioteca compartida, de lo contrario, no podría vincular en tiempo de ejecución? ¿Cómo puede salirse con la suya teniendo referencias no definidas en una biblioteca que se carga en tiempo de ejecución, a menos que las referencias también sean bibliotecas cargables dinámicamente?
De todos modos por lo que si puedo especificar
-undefined suppress -flat_namespace
que no me exige añadir esas opciones -l y -L al crear la biblioteca compartida. Pero todavía no entiendo cómo esto puede funcionar en última instancia.
Gracias, creo que funcionará, pero también estoy interesado en los antecedentes detrás de lo que está sucediendo. – eeeeaaii
MacOS no es bastante Linux. Originalmente es NextOS, después de todo. El enlazador es un poco excéntrico. Agregue -v al libtool y le dirá lo que está haciendo. – bmargulies