c++ - que - mingw gcc 64 bit
Compatibilidad de*.dll*.a*.lib*.def entre VisualStudio y gcc (4)
Me topé con esta pregunta cuando buscaba la herramienta para usar para crear el archivo .a usando el compilador Code :: Blocks c ++ para Windows. Código: Bloques utiliza el compilador gcc de MinGW. Fue lo suficientemente alto en google para validar mi necromancia, creo.
Las bibliotecas de enlaces dinámicos (DLL) son un grupo mixto. Algunos se pueden compilar de una manera que los hace muy difíciles de usar fuera del lenguaje de programación y el compilador con los que fueron creados.
A menudo, sin embargo, la dll se crea con una interfaz C limpia. Cuando ese es el caso, las respuestas a sus preguntas que creo que puedo responder son:
1: eso no es una pregunta.
2, 9: si
3, 10: no
4, 11: sí. MinGW incluye una herramienta (dlltool.exe) que toma un archivo .dll y .def y crea un archivo .a. VisualStudio también incluye una herramienta (que creo que se llama lib.exe) para hacer lo mismo. Y si empiezas a usar otro compilador, probablemente encontrarás que también tienen una herramienta. Los compiladores de Borlands tenían la herramienta implib.exe.
5, 12: sí (igual que 4)
6, 13: banco ... No creo que haya una fecha de caducidad en los archivos DLL, pero deben compilarse para el sistema operativo correcto.
8, 16: necesitas el .def para hacer el .a o .lib, si no lo tienes, en realidad es posible crearlo desde el .dll
esto es muy confuso Pasé mucho tiempo leyendo publicaciones sobre esto en la pila, etc. Todavía confundido.
Estoy usando Qt y C ++ para la codificación. En Qt, estoy usando la opción gcc para un compilador.
El problema es que muchas bibliotecas de terceros que he probado no parecen funcionar.
Soy nuevo en los archivos .dll, .a, .lib, .def y esquemas de biblioteca.
Pregunta 1:
En mi experiencia limitada (hasta ahora he probado con 7 o 9 bibliotecas), los proveedores de bibliotecas rara vez le dicen si el archivo .dll se creó con VisualStudio o gcc. Esto añade mucha confusión. Casi nunca dejan en claro con qué compilador es compatible la biblioteca. Así que apreciaría algunos consejos de la vida real sobre cómo lidiar con esta pesadilla. Casi todas las bibliotecas que probé son proyectos OpenSource. No nombraré nombres aquí, pero estos son proyectos bien conocidos. Estoy seguro de que el problema es mi falta de conocimiento ...
MinGW y gcc world
Pregunta 2:
Por lo que puedo decir, las bibliotecas dinámicas de C ++ para el universo de minGW gcc requieren esto, ¿verdad?
* .h
* .dll
*.una
Pregunta 3:
Desafortunadamente, a menudo falta el archivo .a y la biblioteca no funciona. Esto es muy confuso. Si falta el archivo .a, ¿estoy fuera de suerte?
Pregunta 4:
¿Puedo generar el archivo .a para MinGW / gcc si * .dll se creó con gcc?
Pregunta 5: ¿Puedo generar el archivo .a para MinGW / gcc si * .dll se creó con VisualStudio?
Pregunta 6:
¿Es posible que una * .dll (hecha con MinGW / gcc) sea demasiado antigua y ya no sea compatible con MinGW / gcc más reciente?
Pregunta 7:
Los proyectos Qt que usan MinGW / gcc nunca necesitan archivos * .lib, ¿verdad? Eso es solo una cosa de VisualStudio, ¿verdad?
Pregunta 8:
No necesito un archivo * .def para usar un * .dll en un proyecto Qt usando MinGW / gcc, ¿verdad?
VisualStudio World
Pregunta 9:
Por lo que puedo decir, las bibliotecas dinámicas de C ++ para VisualStudio requieren lo siguiente:
* .h
* .dll
* .lib
¿Derecha? Nuevamente, el problema es que casi siempre falta el archivo * .lib. Además, no hay instrucciones claras sobre con qué compilador es compatible la biblioteca. Entonces, ¿cómo puedo saber que es solo para VisualStudio o no?
Pregunta 10:
Si falta el archivo .lib, ¿estoy fuera de suerte?
Pregunta 11:
¿Puedo generar el archivo .lib para VisualStudio si el * .dll se creó con VisualStudio? ¿Cómo?
Pregunta 12:
¿Puedo generar el archivo .lib para VisualStudio si el * .dll se creó con MinGW / gcc? ¿Cómo?
Pregunta 13:
¿Es posible que una * .dll (hecha con VisualStudio) sea demasiado antigua y ya no sea compatible con VisualStudio más reciente?
Pregunta 14:
Si en QtCreator selecciono el compilador de VisualStudio, ¿es 100% compatible con las bibliotecas dinámicas compiladas con REAL VisualStudio por otra persona? Creo que la opción del compilador de VisualStudio en Qt Creator es un compilador falso de VisualStudio.
Pregunta 15:
Si en QtCreator selecciono el compilador MinGW / gcc, ¿puedo usarlo con las bibliotecas dinámicas Qt compiladas con REAL VisualStudio por otra persona?
Pregunta 16:
No necesito un archivo * .def para usar un * .dll en un proyecto Qt usando MinGW / gcc, ¿verdad?
Pregunta 17: ¿Puedo convertir un archivo * lib (que funciona con un archivo * .dll y * .h) creado con REAL VisualStudio en un archivo * .a para poder usar el archivo * .a con el archivo * .dll no modificado, y * .h archivos en un proyecto de Qt gcc?
Tal vez valga la pena comenzar por el principio y no saltarnos adelante y describir el problema central. De esto se pueden derivar respuestas a varias de las preguntas.
El inicio es el ABI (interfaz binaria de aplicación). Esto define cosas como
- cómo se llama una función, por ejemplo, qué parámetros entran en qué registros o qué ubicación en la pila ponen
- cómo se lanzan las excepciones
- cómo se distribuyen los objetos, por ejemplo, a dónde va el "puntero de vtable", qué relleno se usa
- qué tan grandes son los tipos de datos incorporados
- cómo los nombres de las funciones se "dividen" en símbolos
- cómo se distribuye la información de tipo
- El diseño de las clases de la biblioteca estándar.
- etc.
La mayoría de las plataformas definen un ABI de C, pero no definen un ABI de C ++. Como resultado, el compilador define su propio ABI (para todo excepto el material C que normalmente está ahí). Esto produce archivos de objetos que son incompatibles entre diferentes compiladores (a veces incluso entre versiones del mismo compilador).
Por lo general, esto se manifiesta en nombres de aspecto extraño que de alguna manera están indefinidos: diferentes ABIs utilizan deliberadamente diferentes nombres de nombres para evitar la vinculación accidental de un ejecutable que no funcionará de todos modos. Para evitar esto, lo mejor es construir todos los componentes utilizando el mismo compilador.
Si desea determinar con qué compilador se construye una biblioteca, puede echar un vistazo a su contenido utilizando las herramientas adecuadas. Me doy cuenta de que pidió Windows, pero solo conozco las herramientas de UNIX (pueden estar disponibles con MingW):
- nm para ver los nombres de los símbolos (generalmente junto con less o grep)
- ar para construir o inspeccionar bibliotecas
- Ident para encontrar cadenas especiales incrustadas en el objeto
- cuerdas para tocar todas las cuerdas
- c ++ filt para demangle símbolos en su declaración de C ++
Al observar los símbolos, generalmente se obtienen identificaciones de lo que el compilador los produjo. Si los ha visto con suficiente frecuencia, incluso puede distinguir el ABI a partir de los símbolos mismos.
Hay mucho más en esta área, pero me he quedado sin energía ... :-) En cualquier caso, creo que esto responde a varias de las preguntas anteriores.
Una DLL es esencialmente una aplicación compilada, simplemente en forma de una biblioteca de funciones en lugar de un archivo EXE. Cualquier otra aplicación puede usar las funciones dentro de esa DLL simplemente declarando la función, la dll que contiene la función y los parámetros y valores de retorno y demás.
Las DLL ya deben existir en un sistema si una aplicación se compila con "bibliotecas vinculadas dinámicamente", por lo que debe incluir las DLL necesarias en su instalador, o esperar que ya existan en la computadora de destino. El uso de DLL reduce el tamaño de su aplicación en general.
Crear DLL es como crear cualquier otra aplicación: solo tiene como objetivo su compilación como DLL en lugar de EXE o lo que sea.
Para crear cualquier aplicación (DLL, EXE o de otro tipo) necesita el código fuente y los encabezados necesarios. Los archivos .h contienen declaraciones de funciones y tipos de datos y clases y otras cosas, rara vez contienen código. Un .def es muy parecido a un .h, pero generalmente es un conjunto de instrucciones para un enlazador.
Cuando compilas, un .h o .c o lo que sea se convierte en un .obj - un archivo objeto. Varios archivos de objetos están vinculados entre sí para crear su DLL o EXE.
Un archivo .lib es una biblioteca estática, esencialmente un conjunto de archivos .obj (o uno .obj) que se han combinado para la etapa de enlace.
El formato de los archivos .obj y .lib puede ser particular para un compilador, y rara vez son compatibles entre compiladores. Debe tener el código fuente original o un .obj o .lib creado específicamente para su compilador.
Cuando elija crear un EXE con "bibliotecas enlazadas dinámicamente", estará esperando DLL que pueda usar. Cuando elija "bibliotecas enlazadas estáticamente", el vinculador localizará los archivos .lib que necesita antes de generar el EXE, y no necesitará esos DLL.
pregunta 1: debe importar el archivo .h y vincular el archivo .a mediante el comando del vinculador y copiar .dll cerca de su salida .exe .
pregunta 2: puedes hacer .a archivo .a por .def archivo .def
set PATH=C:/Program Files/CodeBlocks/MinGW/bin;%PATH%
dlltool.exe -d libfftw3-3.def -l libfftw3-3.a
pregunta 3: no. Puedes hacer el archivo .def manualmente y después de hacer el archivo .a .
pregunta 4,5: si
pregunta 6: Creo que depende de su hardware y sistema operativo, no de su compilador.
Pregunta 7: No lo sé.
pregunta 8: solo necesitas .h .a .dll no .def
pregunta 9: los archivos .lib son para visual studio.
pregunta 10: no necesitas .def y .dll para crear .lib y puedes crear . def . def usted mismo si no lo tiene.
set PATH=C:/Program Files/Microsoft Visual Studio 12.0/VC/bin;%PATH%
lib /machine:x86 /def:libfftw3-3.def
o
lib /machine:x64 /def:libfftw3-3.def
Pregunta 11: sí te lo dije arriba.
pregunta 12: si
pregunta 13: no.