c++ - significa - Enlace estático y dinámico/compartido con MinGW

posicionar imagenes

Question

Quiero comenzar con un simple uso de enlaces para explicar mi problema. Supongamos que hay una biblioteca z que se puede compilar en la biblioteca compartida libz.dll (D: /libs/z/shared/libz.dll) o en la biblioteca estática libz.a (D: / libs / z / static / libz .un).

Deje que quiera vincularlo, entonces hago esto:

gcc -o main.exe main.o -LD:/libs/z/static -lz

De acuerdo con esta documentación , gcc buscaría libz.a, que es

archivar archivos cuyos miembros son archivos objeto

También puedo hacer lo siguiente:

gcc -o main.exe main.o -LD:/libs/z/shared -lz

No se menciona en la documentación anterior que -l flag buscará lib<name>.so .

¿Qué pasará si libz.a y libz.dll estarán en el mismo directorio? ¿Cómo se vinculará la biblioteca con un programa? ¿Por qué necesito los indicadores -Wl,-Bstatic y -Wl,-Bdynamic si -l busca bibliotecas compartidas y estáticas?

¿Por qué algunos desarrolladores proporcionan archivos .a con archivos .dll para los mismos módulos, si compilo una distribución de biblioteca compartida?

Por ejemplo, Qt proporciona archivos .dll en el directorio bin con archivos .a en el directorio lib. ¿Es la misma biblioteca, pero construida como compartida y estática, respectivamente? O bien, ¿los archivos son algún tipo de bibliotecas ficticias que proporcionan enlaces con bibliotecas compartidas, donde existen implementaciones de bibliotecas reales?

Otro ejemplo es la biblioteca OpenGL en Windows. ¿Por qué cada compilador debe proporcionar la lib OpenGL estática como libopengl32.a en MingW?

¿Para qué se utilizan los archivos con las extensiones .dll.a y .la?

PD: Aquí hay muchas preguntas, pero creo que cada una depende de la anterior y no hay necesidad de dividirlas en varias preguntas.

Answer 1

Por favor, eche un vistazo a ld y WIN32 (cygwin / mingw) . Especialmente, el enlace directo a una sección dll para obtener más información sobre el comportamiento del indicador -l en los puertos de Windows de LD. Extraer:

Por ejemplo, cuando se llama a ld con el argumento -lxxx, intentará encontrar, en el primer directorio de su ruta de búsqueda,

libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll

antes de pasar al siguiente directorio en la ruta de búsqueda.

(*) En realidad, esto no es cygxxx.dll pero de hecho es <prefix>xxx.dll , donde <prefix> se establece mediante la opción ld -dll-search-prefix=<prefix> . En el caso de cygwin, el archivo de especificaciones estándar de gcc incluye -dll-search-prefix=cyg , por lo que en realidad buscamos cygxxx.dll .

NOTA: si alguna vez ha creado Boost con MinGW, probablemente recuerde que la denominación de las bibliotecas de Boost obedece exactamente al patrón descrito en el enlace anterior.

En el pasado había problemas en MinGW con enlaces directos a *.dll , por lo que se aconsejaba crear una biblioteca estática lib*.a con símbolos exportados desde *.dll y enlazar en su lugar. El enlace a esta página wiki MinGW ahora está muerto, así que supongo que debería estar bien enlazar directamente contra *.dll ahora. Además, lo hice varias veces con la última distribución de MinGW-w64, y todavía no tenía problemas.

Necesita -Wl,-Bstatic enlace -Wl,-Bstatic y -Wl,-Bdynamic porque a veces desea forzar el enlace estático, por ejemplo, cuando la biblioteca dinámica con el mismo nombre también está presente en una ruta de búsqueda:

gcc object1.o object2.o -lMyLib2 -Wl,-Bstatic -lMyLib1 -Wl,-Bdynamic -o output

El fragmento anterior garantiza que la prioridad de vinculación predeterminada de -l indicador se invalida para MyLib1 , es decir, incluso si MyLib1.dll está presente en la ruta de búsqueda, LD elegirá libMyLib1.a para enlazar. Tenga en cuenta que para MyLib2 LD volverá a preferir la versión dinámica.

NOTA: Si MyLib2 depende de MyLib1 , MyLib1 se vincula dinámicamente, independientemente de -Wl,-Bstatic (es decir, se ignora en este caso). Para evitar esto, también debería vincular MyLib2 estáticamente.