Qt 6 undefined reference to WinMain on MinGW

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