Qt 6 undefined reference to WinMain on MinGW

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..

j255

I'm running into this in windows. I've been looking at the qmake -d 2>&1 of a Qt example vs a QWT example. At some point in the QWT qmake generation it seems to loose the entrypoint_private module.

qt example: DEBUG 1: C:/tools/Qt/6.4.2/msvc2019_64/mkspecs/features/qt_functions.prf:379: modules := core gui entrypoint_private
qwt example: DEBUG 1: C:/tools/Qt/6.4.2/msvc2019_64/mkspecs/features/qt_functions.prf:379: modules := core gui printsupport concurrent opengl openglwidgets svg

I haven't been able to figure out the clean fix yet. I ended up diffing the makefiles between the examples and one the major differences was that the QWT example was missing the lib: Qt6EntryPoint.lib
So I added it to the qwt example pro like:
LIBS += C:\Qt\6.4.2\msvc2019_64\lib\Qt6EntryPoint.lib

and then the release version at least built successfully.

note: for diffing the qmake -d output it's handy to do a cut like this (powershell):
qmake -d 2>&1 | % { $_ -split ':' | select -last 1 }

this strips out a lot of paths making the diff easier to scan.
This was using Qwt 6.2.0, git sha:92baef.