diff options
| author | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2020-10-21 15:08:26 +0200 |
|---|---|---|
| committer | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2020-10-26 20:10:48 +0100 |
| commit | 525372c56771a548ac2842ee860730c6ad1e5577 (patch) | |
| tree | 4c18e6d4a0ed9153181c604a216fda9a547489ac /src/widgets/doc/snippets/mainwindowsnippet.cpp | |
| parent | 851e1cb4c4adc6ab6535a5b37803101e4dd4a0d4 (diff) | |
cmake: Ensure Mingw builds pick up and use the WinMain entry point
The cmake code path didn't export QT_NEEDS_QMAIN as a public define
to be inherited by consumers. As a result, the users's main() would
be defined as normal (instead of being named qMain). This in turn
would lead mingw to pick main() as the entrypoint during link time.
We want to go through our WinMain entrypoint (for now), even if
MingGW today has mechanisms for calling the user's main() directly,
as our WinMain uses GetCommandLineW() and as a result prevents
the arguments to main() from being wildcard expanded. and we
want to keep parity between qmake and CMake in how this behaves,
even if we end up changing it in the future.
We follow what qmake does, and expose QT_NEEDS_QMAIN to clients.
With the user's main being then named qMain, mingw will look for
our WinMain.
This in turn leads to the problem of static link ordering, where
adding -lmingw32 as a dependency of the static library target
results in it ending up _after_ the static library during link
time, and the static linker ends up discarding the entry point
library.
To solve this, we split the entry point module into two targets,
one for consumers, and one internal that is the actual static
library. By adding the -lmingw32 dependency to the former target,
we ensure it's added before the static library during linking.
Change-Id: I342c979f56669d5a5a5c237f476556c4e2baf432
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Diffstat (limited to 'src/widgets/doc/snippets/mainwindowsnippet.cpp')
0 files changed, 0 insertions, 0 deletions
