8

Tengo un proyecto C++ no administrado en Visual Studio 2010. Utiliza boost, exceso y otra biblioteca de un proveedor.Enlace e implementación dinámicos y estáticos en Visual Studio 2010

He configurado el proyecto para crear un ejecutable más "dll-indepenendent" posible. Todas las bibliotecas de refuerzo están vinculadas estáticamente y no hay necesidad de dll en el directorio donde permanece el ejecutable.

Lo mismo para el Glut, he vinculado el glut32.lib estático en lugar del glut32.dll y tampoco hay problema.

He seleccionado para las bibliotecas Runtime la versión NO-dll, es decir, Depuración multiproceso (para la configuración de depuración) y Configuración multiproceso para la versión.

Ahora, el proveedor del que hablaba anteriormente, proporciona dos alternativas, Vendor.lib y Vendor.dll.

Vendor.lib se agrega en Linker-> Additional dependencias, pero en tiempo de ejecución siempre tengo que poner Vendor.dll en el mismo directorio del ejecutable, de lo contrario, el entorno de ejecución se queja porque no encuentra el proveedor Biblioteca .dll.

¿Cómo debo resolver este problema? Me gustaría evitar poner en cada directorio el archivo .dll.

No quiero poner el dll en el mismo directorio del exe y, en general, ¿cuáles son las pautas para implementar aplicaciones de consola C++ no administradas en Visual Studio?

Sé que hay muchas preguntas y páginas sobre este argumento, pero ninguna de ellas me aclaró este punto.

¿Alguna idea?

Respuesta

10

Microsoft es un poco gracioso en la forma en que maneja esto: cuando creas un .dll , también creas un .lib, que contiene los símbolos públicos en el .dll. Debe enlazar con .lib para cargar el .dll en el tiempo de ejecución , pero esta .lib aún no es una biblioteca estática. Si su proveedor proporciona una versión para enlace estático, no habrá .dll, o dos .lib (presumiblemente en directorios diferentes o con nombres diferentes). Simplemente otro ejemplo de Microsoft haciendo un desarrollo serio más difícil de lo necesario.

+2

Esto no es específico de MS. Linux también tiene bibliotecas de importación. – rubenvb

+8

Unix tiene dos tipos de "bibliotecas": bibliotecas (archivos .a) y objetos compartidos (archivos .so).Un proveedor que proporciona una biblioteca (en el sentido general) normalmente proporcionará ambos. Si enlaza con el archivo .a, se enlaza estáticamente y si enlaza con el .so, se vincula dinámicamente. El problema con la solución de Microsoft es que 1) tiene dos archivos distintos para la vinculación dinámica, y 2) uno de los archivos tiene el mismo nombre que una biblioteca estática. –

+0

Gracias por su respuesta. Probablemente no soy el único confundido en este tema. Entonces, como dices, hay dos tipos de archivos .lib, uno creado cuando se necesita una biblioteca dinámica y otro que puede ser una biblioteca estática. No encuentro otro archivo Vendor.lib, así que supongo que estoy en el primer caso ... ¡Gracias! – linello

7

Vendor.lib debe ser una biblioteca compilada estáticamente. Si al vincular esto, aún necesita Vendor.dll, parece que Vendor.lib es en realidad una biblioteca de importación en lugar de una biblioteca estática.

Compruebe si el proveedor proporciona otro Vendor.lib (que debe ser un poco más grande que su .lib actual) que es una biblioteca estática e intente vincularlo. Si es así, no necesitarás el dll.

+0

Desafortunadamente no tengo otros archivos .lib en esa biblioteca, así que supongo que estoy en el caso del enlace dinámico. No hay otros métodos para incluir el .dll en lugar de copiarlo en el directorio ejecutable (o copiarlos en la carpeta System32?) – linello

+0

Si tiene acceso a la fuente del proveedor, puede compilar el vendor.lib usted mismo como una biblioteca estática . De lo contrario, si tiene que usar la biblioteca compartida, su exe necesita acceder a esto en tiempo de ejecución, lo que significa agregarlo a la carpeta con el exe, o ponerlo en una carpeta que se incluye en% PATH% (la convención es la Carpeta System32). – Fraser