referencia indefinida a `WinMain @ 16 ‘

Cuando bash crear un progtwig usando Eclipse CDT , obtengo lo siguiente:

/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x106): referencia no definida a `WinMain @ 16

¿Porqué es eso? Y, ¿cómo puedo resolver este problema?

Considere el siguiente progtwig de nivel de API de Windows:

 #define NOMINMAX #include  int main() { MessageBox( 0, "Blah blah...", "My Windows app!", MB_SETFOREGROUND ); } 

Ahora construyamos usando la cadena de herramientas GNU (es decir, g ++), sin opciones especiales. Aquí gnuc es solo un archivo por lotes que uso para eso. Solo proporciona opciones para hacer que g ++ sea más estándar:

 C: \ test> gnuc x.cpp

 C: \ test> objdump -x a.exe |  findstr / i "^ subsistema"
 Subsistema 00000003 (Windows CUI)

 C: \ prueba> _

Esto significa que el enlazador produjo de manera predeterminada un ejecutable del subsistema de consola . El valor del subsistema en el encabezado del archivo le dice a Windows qué servicios requiere el progtwig. En este caso, con el sistema de consola, el progtwig requiere una ventana de consola.

Esto también hace que el intérprete de comandos espere a que se complete el progtwig.

Ahora construyamos con el subsistema GUI , lo que significa que el progtwig no requiere una ventana de consola:

 C: \ test> gnuc x.cpp -mwindows

 C: \ test> objdump -x a.exe |  findstr / i "^ subsistema"
 Subsistema 00000002 (GUI de Windows)

 C: \ prueba> _

Afortunadamente, eso está bien hasta ahora, aunque la bandera de -mwindows está simplemente semi-documentada.

Construir sin esa bandera semi-documentada tendría que decirle al enlazador qué valor de subsistema desea, y algunas bibliotecas de importación de API de Windows tendrán que especificarse explícitamente en general:

 C: \ test> gnuc x.cpp -Wl, -subsystem, windows

 C: \ test> objdump -x a.exe |  findstr / i "^ subsistema"
 Subsistema 00000002 (GUI de Windows)

 C: \ prueba> _

Eso funcionó bien, con la cadena de herramientas GNU.

Pero, ¿qué hay de la cadena de herramientas de Microsoft, es decir, Visual C ++?

Bueno, construir como un ejecutable del subsistema de consola funciona bien:

 C: \ test> msvc x.cpp user32.lib
 x.cpp

 C: \ test> dumpbin / headers x.exe |  encontrar / i "subsistema" |  encontrar / i "Windows"
                3 subsistema (Windows CUI)

 C: \ prueba> _

Sin embargo, con la construcción de la cadena de herramientas de Microsoft como subsistema GUI no funciona por defecto:

 C: \ test> msvc x.cpp user32.lib / link / subsystem: windows
 x.cpp
 LIBCMT.lib (wincrt0.obj): error LNK2019: símbolo externo sin resolver _WinMain @ 16 al que se hace referencia en la función ___tmainCRTStartu
 pag
 x.exe: error fatal LNK1120: 1 external externo sin resolver

 C: \ prueba> _

Técnicamente, esto se debe a que el enlazador de Microsoft no es estándar por defecto para el subsistema GUI . De forma predeterminada, cuando el subsistema es GUI, el enlazador de Microsoft usa un punto de entrada de la biblioteca de tiempo de ejecución, la función donde se inicia la ejecución del código de máquina, llamada winMainCRTStartup , que llama a WinMain no estándar de WinMain lugar de main estándar.

No es gran cosa para arreglar eso, sin embargo.

Todo lo que tiene que hacer es decirle al enlazador de Microsoft qué punto de entrada usar, a saber, mainCRTStartup , que llama a main estándar:

 C: \ test> msvc x.cpp user32.lib / link / subsystem: windows / entry: mainCRTStartup
 x.cpp

 C: \ test> dumpbin / headers x.exe |  encontrar / i "subsistema" |  encontrar / i "Windows"
                2 subsistema (GUI de Windows)

 C: \ prueba> _

No hay problema, pero es muy tedioso. Y tan arcano y oculto que la mayoría de los progtwigdores de Windows, que en su mayoría solo usan las herramientas no estándar de Microsoft, ni siquiera lo saben, y creen erróneamente que un progtwig de subsistema GUI de Windows “debe” tener WinMain no estándar en lugar de estándar main . De paso, con C ++ 0x, Microsoft tendrá un problema con esto, ya que el comstackdor debe entonces publicitar si es independiente o está alojado (cuando está alojado debe ser compatible con el estándar main ).

De todos modos, esa es la razón por la cual g ++ puede quejarse de la falta de WinMain : es una función de arranque tonta y no estándar que las herramientas de Microsoft requieren por defecto para los progtwigs del subsistema GUI.

Pero como puede ver arriba, g ++ no tiene problema con el estándar main incluso para un progtwig de subsistema GUI.

Entonces, ¿Cuál podría ser el problema?

Bueno, probablemente te estás perdiendo un plato main . ¡Y probablemente tampoco tenga WinMain (apropiado)! Y luego g ++, después de haber buscado main (no existe), y para WinMain no estándar de WinMain (no existe), informa que falta este último.

Prueba con una fuente vacía:

 C: \ test> tipo nul> y.cpp

 C: \ test> gnuc y.cpp -mwindows
 c: / archivos de progtwig / mingw / bin /../ lib / gcc / mingw32 / 4.4.1 /../../../ libmingw32.a (main.o): main.c :(. text + 0xd2 ): referencia indefinida
 ce a `WinMain @ 16 '
 collect2: ld devolvió 1 estado de salida

 C: \ prueba> _

Para resumir la publicación anterior por Cheers y hth. – Alf, asegúrate de tener main() o WinMain() definido y g ++ debería hacer lo correcto.

Mi problema fue que main() se definió por accidente dentro de un espacio de nombres.

Me encontré con este error al comstackr mi aplicación con SDL. Esto fue causado por SDL definiendo su propia función principal en SDL_main.h. Para evitar SDL, defina la función principal que debe definirse una macro SDL_MAIN_HANDLED antes de incluir el encabezado SDL.h.

Intente guardar su archivo .c antes de comstackr. Creo que su computadora está haciendo referencia a una ruta a un archivo sin información dentro de él.

–Tengo un problema similar cuando construyes proyectos C