Pregunta

Abrí un antiguo espacio de trabajo que es una biblioteca y su arnés de prueba.Solía ​​funcionar bien, pero ahora no funciona y las versiones anteriores del código tampoco funcionan con los mismos errores.Intenté recrear el proyecto y eso también causa los mismos errores.Nada parece desordenado en la configuración del proyecto y el código generado funciona en la aplicación principal.

Eliminé la mayoría de los archivos y los reduje al mínimo para generar el error.Desafortunadamente no puedo publicar el proyecto ya que se usa en el código de producción.

El error del vinculador LNK2001 que recibo generalmente significa que dejé una biblioteca o que olvidé implementar una función virtual.Sin embargo, esto es parte de la biblioteca de plantillas estándar y, además, es un encabezado.

El código que aparece como problemático en IOCompletionPort.obj en realidad no utiliza std::string directamente, pero llama a una clase que hace: Comms::Exception acepta un std::string y el valor de GetLastError o WSAGetLastError.

La función mencionada en el error (GetMessage) está implementado, pero es una función virtual por lo que otras clases pueden anularla si es necesario.Sin embargo, parece que el compilador lo creó como una versión Ansi, pero no puedo encontrar ninguna opción en la configuración que pueda controlar eso.Sospecho que ese podría ser el problema, pero como hay muy pocas opciones para la biblioteca, no tengo forma de saberlo con seguridad.Sin embargo, ambos proyectos deben especificar _MBCS en las opciones del compilador.

--------------------Configuración:TestComms - Depuración de Win32 -------------------- Vinculación...Comms.lib (iocompletionPort.obj):error LNK2001:símbolo externo no resuelto "público:Clase virtual std :: básico_string, clase std :: allocator> __thiscall comms :: excepción :: getMessagea (void) const "(? @@ v? $ Allocator@d@2 @@ std @@ xz) debug/testcomms.exe:error grave LNK1120:1 Error externo no resuelto Ejecutando Link.exe.

TestComms.exe: 2 errores, 0 advertencias

¿Alguna sugerencia?He perdido la mayor parte de la mañana con esto y no quiero perder también la mayor parte de la tarde.

¿Fue útil?

Solución

Una posibilidad reside en la "manipulación de nombres" ANSI/Unicode de Win32, que convierte el símbolo GetMessage en cualquiera de los dos GetMessageA o GetMessageW.Hay tres posibilidades:

  1. Windows.h no se ha cargado, por lo que GetMessage corsé GetMessage

  2. Windows.h se cargó con símbolos configurados para ANSI, por lo que GetMessage se convierte GetMessageA

  3. Windows.h se cargó con símbolos configurados para Unicode, por lo que GetMessage se convierte GetMessageW

Si ha compilado dos archivos diferentes de manera que desencadenen dos escenarios diferentes, obtendrá un error del vinculador.El mensaje de error indica que el Comms::Exception La clase era una instancia del n.° 2 anterior. ¿Quizás se usa en algún lugar donde Windows.h no se ha cargado?

Otras cosas que haría en tu lugar, simplemente como una cuestión de rutina:

1) Asegúrese de que mis rutas de inclusión y biblioteca no contengan nada que no espero.

2) Realice una "limpieza de compilación" y luego verifíquela manualmente, eliminando cualquier archivo de objeto adicional si es necesario.

3) Asegúrese de que no haya rutas codificadas en las declaraciones de inclusión que no signifiquen lo que significaban cuando se reconstruyó originalmente el proyecto.

EDITAR:Luchando con el formato :(

Otros consejos

@Brusco:Creo que fuiste el que más se acercó.No he probado esto, pero creo que di la respuesta en mi pregunta original.

Obtener mensaje es una definición en Windows.h envuelta en un bloque ifndef para cambiar entre Ansi (GetMessageA) y Unicode (GetMessageW).

Suponiendo que no haya perdido el tiempo con la configuración del Proyecto eliminando algo que no debería tener (que es donde esperaría que estuvieran las dependencias externas como User32.lib):

Verificar herramientas | Opciones | Directorios | Bibliotecas (que van de la memoria aquí) y asegúrese de que no se pierda los directorios de Lib de variedad de todo el jardín (nuevamente, sin VC6 frente a mí, no puedo decirle qué son)

Este es un problema general con la forma en que Microsoft manejó la norma ANSI vs.API Unicode.Dado que todos (o casi todos) se realizan definiendo macros para los nombres de funciones que se resuelven en las versiones 'A' o 'W' de los nombres de funciones, no puede tener de forma segura un identificador en su espacio de nombres/clase/struct/enum/ función que coincide con un nombre de API de Windows.

Las macros windows.h pisotean todos los demás espacios de nombres.

windows.h se declara en la parte superior de IOCompletionPort.h como una inclusión. Estaba harto de ver 7 líneas solo para incluir 1 archivo, así que lo envolví en su propio archivo y lo incluí.Esto también contiene algunas #definiciones adicionales (es decir, ULONG_PTR), ya que nuestra aplicación principal no se compilará con el SDK de plataforma instalado:-(

  1. Eso está confirmado.Nada está fuera de lugar.
  2. Lo hice: eliminé los directorios de compilación.
  3. Nunca uso rutas codificadas.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top