Qt 6 undefined reference to WinMain on MinGW

[VRonin]

I came across a problem and I have no idea what is causing it.

I have a project with a library + a number of example apps and tests linking to it and I'm using CMake as build system.
When I'm using the combo:

• Qt 6.0
  • Qt 5.15, 5.12, 5.9 and 5.1 all work
• MinGW compiler
  • MSVC, Clang and g++ all work
• I dynamically link my library
  • static library works.

I get undefined reference to 'WinMain' when building the applications.
Any idea what I am doing wrong here?

If useful, the full CI log can be found here

[Christian Ehrlicher]

https://bugreports.qt.io/browse/QTBUG-93671

[Christian Ehrlicher]

I've not problems with Qt6.0.3 (binaries installed through installer). Maybe try to explicitly link against Qt6::EntryPoint. All this magic with WinMain (=subsystem Windows) or main (=subsystem Console) is done in qtentrypoint_win.cpp

[VRonin]

@Christian-Ehrlicher This was a good guess but unfortunately didn't fix the problem

[Christian Ehrlicher]

But this really has to do something with the subsystem. Maybe you have to add WIN32 (or accidentally added it): https://cmake.org/cmake/help/latest/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE . But strange that it works fine for me...

[VRonin]

I still don't understand why, if the library target is a static lib, everything works fine.
Qt 6.1 exibits the same problem.

I created a minimal example repository. If someone is using Qt 6 on MinGW 8.1 64 bits, can please clone it, add the CMake variable BUILD_SHARED_LIBS=ON and build it?
I'm starting to think it might be a problem of the CI machine

[Christian Ehrlicher]

As expected it's the WIN32 keyword in add_executable()
Without this the linking works fine (because then the entry point is main and not WinMain). Now I've something to play with.

btw: you forgot to specify the BUILD_SHARED_LIBS as OPTION.

/edit: now it compiles and links fine without any changes on my side !?

[VRonin]

@Christian-Ehrlicher said in Qt 6 undefined reference to WinMain on MinGW:

As expected it's the WIN32 keyword in add_executable()

Yes, confirmed, but it's not acceptable, without that keyword the executable will be a console application (the equivalent of CONFIG += console in qmake).

btw: you forgot to specify the BUILD_SHARED_LIBS as OPTION.

It's not an option it's built into CMake

[Christian Ehrlicher]

@VRonin said in Qt 6 undefined reference to WinMain on MinGW:

It's not an option it's built into CMake

'This variable is often added to projects as an option() so that each user of a project can decide if they want to build the project using shared or static libraries.'

I'm lazy and just want to activate an option :)

And your new project again gives the linker error when WIN32 is specified

[Christian Ehrlicher]

And one more, please try:

-target_link_libraries(MyLib PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets)
+target_link_libraries(MyLib PUBLIC Qt6::Core Qt6::Gui Qt6::Widgets)

:)

A cmake problem with some dependencies when a library is linked PRIVATE in a lib and then directly in an application?

[Christian Ehrlicher]

Found it - link order problem: libQt6EntryPoint.a must be after -lmingw32 in the link order (linklibs.rsp). Will dig deeper how to fix it.

[VRonin]

@Christian-Ehrlicher ABSOLUTE LEGEND!

[VRonin]

@Christian-Ehrlicher said in Qt 6 undefined reference to WinMain on MinGW:

-target_link_libraries(MyLib PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets)
+target_link_libraries(MyLib PUBLIC Qt6::Core Qt6::Gui Qt6::Widgets)

This fixes the build for some reason

[Christian Ehrlicher]

@VRonin said in Qt 6 undefined reference to WinMain on MinGW:

This fixes the build for some reason

Linking all Qt libraries private for a shared lib somehow confuses cmake so INTERFACE_LINK_LIBRARIES is not interpreted when linking against this lib and the Qt libraries later on.

btw: PRIVATE is not correct, it should be PUBLIC and therefore it was not noticed until now.

[VRonin]

@Christian-Ehrlicher said in Qt 6 undefined reference to WinMain on MinGW:

PRIVATE is not correct, it should be PUBLIC

In this particular case it is indeed wrong but if you think of a library not exposing Qt (for example, a library to read/write xml files that internally uses QXmlStreamReader/QXmlStreamWriterer), the application linking to it might or might not link to Qt itself so PUBLIC in that case would be wrong.
If this is unclear I can change the minimal example to show what I mean

[Christian Ehrlicher]

@VRonin It's not unclear. Just a reason why noone noticed until now :)

[Christian Ehrlicher]

https://bugreports.qt.io/browse/QTBUG-93671

[supa5000]

Dear all,

i write here for fellow googlers.

I stumbled to this thread with setup of msys2 - toolchain + qt6 binaries "mingw81_64". The project compiled fine under QT5 (and it compiles fine with qt6 on linux / ubuntu 20.04) - but with qt6.1.0 it failed on windows.

I did have a library, but it was not qt6 depending, like

add_library( foo_common STATIC )
add_library( foo_engine  STATIC )
target_link_libraries( foo_engine PRIVATE foo_common )
...
add_executable( ${NAME} ... )
target_link_libraries( ${NAME} PUBLIC Qt6::Widgets )
target_link_libraries( ${NAME} PRIVATE foo_common foo_engine )

I did try few swap places but it had no effect. Finally i added suggested

target_link_libraries( ${NAME} PUBLIC Qt6::EntryPoint)

after the existing target_link_libraries calls and it did work.

[VRonin]

@supa5000 said in Qt 6 undefined reference to WinMain on MinGW:

I did try few swap places

Try replacing

target_link_libraries( ${NAME} PUBLIC Qt6::Widgets )
target_link_libraries( ${NAME} PRIVATE foo_common foo_engine )

with

target_link_libraries( ${NAME} PRIVATE foo_common foo_engine Qt6::Widgets)

while it is a workaround it worked for me

[supa5000]

@VRonin said in Qt 6 undefined reference to WinMain on MinGW:

while it is a workaround it worked for me

Thanks for the detail - i tried but the result remained for some reason the same. I did - to be sure - try fresh (rm -rf build && cd build && cmake ../ && make) build but no effect.

To give the full details the actual link line was (that did not work until the entrypoint explicitly linked below)

target_link_libraries( ${name} PRIVATE foo_common foo_engine Qt6::Widgets Qt6::Qml Qt6::Quick)
# Try2: target_link_libraries( ${name} PRIVATE foo_common foo_engine Qt6::Qml Qt6::Quick Qt6::Widgets)
# enabling this makes the link go ok.
# target_link_libraries( ${name PUBLIC Qt6::EntryPoint)

i tried also (as comment try2) move the Widgets as the last item but it seemed not have effect.

[supa5000]

I just pulled 6.2.0 and i stumbled again this; this time the Qt6::Entrypoint target was not found during CMake - so i removed it -- and now i am back with the missing WinMain issue.

Any ideas or updates? The linked bug https://bugreports.qt.io/browse/QTBUG-93671 seems stalled..