Open aminya opened 2 years ago
There is an explicit code that results in this issue. I don't know why just Catch2 doesn't use main on Windows similar to others!
I am pretty sure you are wrong here.
This linking error:
c:/users/runneradmin/gcc/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text+0x46): undefined reference to `WinMain'
means that libmingw32.a
is missing the reference to WinMain
(because Catch2 doesn't provide it, it isn't a GUI subsystem application).
From a quick google, the issue is that you need to add -municode
when building the executable (likely the link step is enough) so that MinGW understands to target wmain
entry point and not main
entry point.
Adding -municode doesn't fix undefined references to `WinMain' https://github.com/aminya/project_options/issues/129
Why do you want to use non-standard wmain on Windows?
-municode
needs to be added as link option, not compile option.
As to your question, wmain
is used on Windows, when you provide _UNICODE
define during compilation. This means that you require support for unicode, which requires wmain
so that you can accept wchar_t
(unicode-ish) arguments.
If you want to keep this Unicode default on MinGW, you should handle -municode
inside Catch2's CMake files. By default, it is not possible to build a simple test on MinGW.
Adding -municode
to the link options changes the error: undefined reference to 'wWinMain'
https://github.com/aminya/project_options/runs/6819912259?check_suite_focus=true#step:5:458
cmd.exe /C "cd . && C:\Users\runneradmin\gcc\mingw64\bin\g++.exe -O3 -DNDEBUG -municode CMakeFiles/main.dir/Release/src/main/main.cpp.obj -o Release\main.exe -Wl,--out-implib,Release\libmain.dll.a -Wl,--major-image-version,0,--minor-image-version,0 vcpkg_installed/x64-mingw-static/lib/libfmt.a --coverage -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cmd.exe /C "cd /D D:\a\project_options\project_options\test\build && "C:\Program Files\PowerShell\7\pwsh.exe" -noprofile -executionpolicy Bypass -file C:/Users/runneradmin/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary D:/a/project_options/project_options/test/build/Release/main.exe -installedDir D:/a/project_options/project_options/test/build/vcpkg_installed/x64-mingw-static/bin -OutVariable out""
c:/users/runneradmin/gcc/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/users/runneradmin/gcc/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_w.o):crt0_w.c:(.text+0x41): undefined reference to `wWinMain'
Mingw doesn't use wmain
as wWinMain
. It might be because the function prototype looks different than what Catch2 is using.
https://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/#unicode-applications
Current MinGW status:
This can be simply fixed by using the standard main function!
@horenmar any update on my comments and pull request?
My build worked using v.3.1.0 but gives undefined reference to WinMain at v.3.2.0. Turns out in cmake I needed to link with Catch2::Catch2WithMain
instead of Catch2::Catch2
For anyone who is still struggling with this, as a last resort you can provide your own main
as per the example: https://github.com/catchorg/Catch2/blob/devel/docs/own-main.md
-DDO_NOT_USE_WMAIN=ON
can make mingw
happy.
Describe the bug Once you define the
CATCH_CONFIG_MAIN
definition on MinGW, it defines a non-standard main function called WinMain. This results in a lot of undefined references. This doesn't happen with other compilers.https://github.com/aminya/cpp_vcpkg_project/runs/6542106054?check_suite_focus=true#step:6:203
Expected behavior
CATCH_CONFIG_MAIN
should define a standard main on MinGWReproduction steps
task test
ormake test
Platform information:
Additional context
Blocks https://github.com/aminya/project_options/issues/129 Related issues: