visual-c++ - sirve - image title

Enlace de error LNK2019 en MSVC, símbolos no resueltos con el prefijo__imp__, pero debe ser de lib estático

Question

Me encuentro con problemas de vinculación en MSVC para un proyecto que escribí para g ++. Aquí está el problema:

Construyo libssh como una biblioteca estática como parte de mi aplicación, agregando el objetivo en cmake con

add_library (ssh_static STATIC $ libssh_SRCS)

Libssh está en C, entonces tengo ''externo'' C "{...} ''envolviendo las inclusiones en mis fuentes de c ++. Luego vinculo el objetivo ssh_static a mi ejecutable, sshconnectiontest, con

target_link_libraries (sshconnectiontest ... ssh_static ...)

Todo esto funciona bien en Linux con gcc, pero ahora en MSVC me sale

error LNK2019: unresolved external symbol __imp__[function names here] referenced in [filename]

para cada función de libssh que uso.

¿Alguna idea de lo que está yendo mal? He leído en alguna parte que el prefijo imp significa que el enlazador espera vincular un .dll, pero este no debería ser el caso, ya que ssh_static se declara una biblioteca estática en la llamada add_library ...

Answer 1

Algo tarde para la fiesta, pero obtuve el mismo error al mezclar bibliotecas con enlaces estáticos y dinámicos a la CRT

Answer 2

No sé si es tu caso, pero el prefijo imp puede significar que estás compilando una biblioteca x64 en un proyecto de Win32.

Answer 3

Por lo que recuerdo de mis días de Windows, en las DLL creadas con MinGW, el prefijo del símbolo __imp__ se usa para la función de trampolín que llama a la DLL propiamente dicha. Este símbolo es provisto por una pequeña biblioteca estática con la extensión .dll.a .

Cuando incluye encabezados de libssh, debe establecer un #define para indicar que espera vincular estáticamente. Si no lo hace, las funciones de libssh en el encabezado se declararán como __declspec(dllimport) y los símbolos __imp__ se esperarán en el tiempo del enlace.

Eché un vistazo a la fuente libssh y encontré esto en la parte superior de libssh.h :

#ifdef LIBSSH_STATIC
#define LIBSSH_API
#else
#if defined _WIN32 || defined __CYGWIN__
#ifdef LIBSSH_EXPORTS
#ifdef __GNUC__
#define LIBSSH_API __attribute__((dllexport))
#else
#define LIBSSH_API __declspec(dllexport)
#endif
#else
#ifdef __GNUC__
#define LIBSSH_API __attribute__((dllimport))
#else
#define LIBSSH_API __declspec(dllimport)
#endif
#endif
#else
#if __GNUC__ >= 4
#define LIBSSH_API __attribute__((visibility("default")))
#else
#define LIBSSH_API
#endif
#endif
#endif

LIBSSH_STATIC definir LIBSSH_STATIC , ya sea a través de #define antes de la línea #include <libssh.h> , o como una opción /D Como está utilizando CMake, probablemente lo haga a través de add_definitions en CMakeLists.txt .

Answer 4

Usando un archivo .DEF

Si elige usar __declspec (dllimport) junto con un archivo .DEF, debe cambiar el archivo .DEF para usar DATA o CONSTANT para reducir la probabilidad de que una codificación incorrecta ocasione un problema:

// project.def
LIBRARY project
EXPORTS
ulDataInDll CONSTANT

La siguiente tabla muestra por qué:

Keyword Emits in the import library Exports
CONSTANT _imp_ulDataInDll _ulDataInDll
_ulDataInDll
DATA _imp_ulDataInDll _ulDataInDll

http://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx

PERO CONSTANT ahora está en desuso

encontré otra forma, en el archivo .DEF del uso de .lib exportado:

 mainthreadid=_mainthreadid

y regenerar la lib con LIB.exe

en el archivo de cabecera de importación del código dll ...

extern "C" {
extern const __declspec(dllexport) ulong mainthreadid;
}