2009-04-20 12 views
8

Estoy en el proceso de portar una gran aplicación de C++ desde Linux (gcc) a Windows (Visual C++ 2008) y tengo problemas con los conectores de los complementos. En Linux, esto no fue un problema, ya que .so admite la búsqueda de símbolos en tiempo de ejecución, pero el dll no parece ser compatible.Visual C++ - DLL de complemento de enlace contra EXE?

Algunos antecedentes: La aplicación (el anfitrión), que alberga un entorno de programación, proporciona interfaces para plugins (bibliotecas compartidas que se cargan en tiempo de ejecución mediante llamadas a la API guión), permitiendo que el anfitrión y la API de secuencias de comandos para extenderse sin recompilar la aplicación de host. En Linux, esto es solo cuestión de incluir los encabezados de la aplicación host en el origen del complemento, pero en Windows recibo errores del enlazador. No estoy seguro de exactamente con qué necesito vincularme para que Visual C++ resuelva estos símbolos.

Una de nuestras dependencias (código abierto, LGPL) tiene declaraciones de preprocesador que utiliza para insertar __declspec (dllexport) y __declspec (dllimport) en sus encabezados. Algunas investigaciones previas indican que quizás tenga que hacer esto también, pero me gustaría estar seguro antes de modificar un montón de encabezados centrales. (Anteriormente pude hacer esto trabajando en MinGW, pero hemos decidido que el soporte de Visual Studio es un requisito para este tipo de proyecto comercial.)

Mi pregunta, en pocas palabras: ¿Cómo se vincula el tiempo de ejecución- dlls cargados contra un exe de host en Visual C++?

Editar: Para aclarar el problema con un ejemplo, tengo una clase en mi aplicación host, Objeto, que representa el tipo de base de un objeto que se pueda acceder por un guión. En mis complementos, tengo varias clases que extienden Objeto para realizar otras funciones, como la integración del soporte de red o nuevos elementos visuales. Esto significa que mi dll debe vincularse con símbolos en el host exe, y no estoy seguro de cómo hacerlo.

+0

Estoy teniendo un poco de problemas para resolver esto. Si tiene un ejemplo concreto y lo simplifica con unas pocas líneas de código, tal vez eso ayude a todos a ayudarlo. – ojblass

Respuesta

5

¿Qué quiere decir con "runtime symbol searchup"? ¿Te refieres a cargar bibliotecas dinámicamente usando dlopen y dlsym y so on? El equivalents in Windows se llama LoadLibrary y GetProcAddress.

En Windows, no exporta símbolos de un archivo ejecutable. Solo debe exportarlos desde un dll. La forma correcta de resolver su problema es realizar una nueva configuración para que los símbolos exportados estén en un dll que el archivo ejecutable y otros archivos DLL de complemento pueden vincular.

+0

Eso es exactamente, y puedo hacerlo bien, pero no puedo entender cómo compilar ese dll contra símbolos definidos en mi ejecutable de host (Ver mi edición reciente) –

+4

Puede exportar símbolos desde un archivo EXE; simplemente use GetProcAddress (GetModuleHandle (NULL), "MyProc)) para recogerlos. –

+1

... pero el cargador de Windows no hará esto automáticamente. –

1

No se puede, fácilmente. El cargador de Windows no está diseñado para exportar símbolos de un EXE y vincularlos a símbolos en un archivo DLL.

Un patrón que he visto es el DLL exportar una determinada función que el EXE llama. Toma como parámetro una estructura que contiene direcciones de funciones en el EXE para que la DLL llame.

1

Como dice 1800 INFORMATION, no lo haga así. Mueva el objeto fuera del ejecutable a una "tercera" DLL. Vincular los complementos y el ejecutable con eso.

1

He estado implementando lo mismo, construyendo una biblioteca de complementos para compilar bajo Linux y Windows.

La solución en Linux es usar la opción -dinámica en la línea de comando gcc. Esto exporta todos los símbolos en el ejecutable principal, de modo que un complemento pueda encontrarlos en la carga.

En Windows, la solución es agregar __declspec (dllexport) delante de la definición de esas funciones en el exe que desea que usen los dlls.La compilación creará un archivo .lib para que los dlls se vinculen. Ciertamente funciona bajo Visual studio 2008. Publicación relacionada: https://stackoverflow.com/a/3756083/1486836

Cuestiones relacionadas