Qt5 + cmake doesn't seem to work at all #1642
Comments
Static Qt/Cmake has been a long term issue, the helloworld has a whole bunch of linking errors. It's not a real solution, but you can add some helpers using diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8858e19..2dc780e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -6,5 +6,10 @@ set(CMAKE_AUTOUIC ON)
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Gui REQUIRED)
find_package(Qt5Svg REQUIRED)
+
+find_package(PkgConfig REQUIRED)
+pkg_check_modules(QT5SVG Qt5Svg)
+link_directories(${QT5SVG_LIBRARY_DIRS})
+
add_executable(qt5helloworld WIN32 main.cpp mainwindow.cpp)
-target_link_libraries(qt5helloworld Qt5::Widgets Qt5::Gui Qt5::Svg)
+target_link_libraries(qt5helloworld Qt5::Widgets Qt5::Gui Qt5::Svg ${QT5SVG_LIBRARIES}) |
|
It doesn't run however, neither does |
|
I guess the next thing to try is compare the makefiles generated by |
|
Okay, this runs: diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8858e19..14779e8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -6,5 +6,16 @@ set(CMAKE_AUTOUIC ON)
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Gui REQUIRED)
find_package(Qt5Svg REQUIRED)
+
+foreach(plugin ${Qt5Gui_PLUGINS})
+ get_target_property(_loc ${plugin} LOCATION)
+ message("Plugin ${plugin} is at location ${_loc}")
+ set(plugin_libs ${plugin_libs} ${_loc})
+endforeach()
+
+find_package(PkgConfig REQUIRED)
+pkg_check_modules(QT5SVG Qt5Svg)
+link_directories(${QT5SVG_LIBRARY_DIRS})
+
add_executable(qt5helloworld WIN32 main.cpp mainwindow.cpp)
-target_link_libraries(qt5helloworld Qt5::Widgets Qt5::Gui Qt5::Svg)
+target_link_libraries(qt5helloworld Qt5::Widgets Qt5::Gui Qt5::Svg ${plugin_libs} -lQt5PlatformSupport ${QT5SVG_LIBRARIES} )
diff --git a/main.cpp b/main.cpp
index b48f94e..2b246bc 100644
--- a/main.cpp
+++ b/main.cpp
@@ -1,6 +1,9 @@
#include "mainwindow.h"
#include <QApplication>
+#include <QtPlugin>
+Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
+
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
// This file is autogenerated by qmake. It imports static plugin classes for
// static plugins specified using QTPLUGIN and QT_PLUGIN_CLASS.<plugin> variables.
#include <QtPlugin>
Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
Q_IMPORT_PLUGIN(QICOPlugin)
Q_IMPORT_PLUGIN(QGenericEnginePlugin)
Q_IMPORT_PLUGIN(QNativeWifiEnginePlugin)
Q_IMPORT_PLUGIN(QSQLiteDriverPlugin)
Q_IMPORT_PLUGIN(QMYSQLDriverPlugin)
...etcYou should be able to use some of the introspection features of cmake to get the actual plugins you need and link them in order, possibly with some manual ones |
tested on i686-w64-mingw32.shared i686-w64-mingw32.static minimal example for mxe#1642
|
@uwehermann I've added a minimal test build https://github.com/mxe/mxe/pull/1645/files. I haven't tested with *posix, but that should help narrow it down. The key steps seem to be:
Is the Linux build a static build? |
|
@tonytheodore thanks for pointing me here. So should it be possible to work around it with some |
|
@avih #1645 is just an example and doesn't affect any functionality. The changes mentioned above are a starting point for a "smallish" projects, but larger projects (quassel, sigrok) would probably need a fair amount of work to build and maintain. Ideally, qt5 should be patched so the supplied cmake modules are aware of static dependencies, but I can't see there is really even a starting point for that in the way the files are generated. |
|
@tonytheodore thanks. I feel that this is way over my head (I know very little about Qt and cmake), but after some messing about with Which feels to me somewhat related to what #1645 does - possibly related to But anyway, it's probably a waste of time, as I assume it would build successfully when linking dynamically. If you even manage to build quassel client statically, ping me ;) (I can build it on windows using the mingw qt sdk). |
|
Have you looked at the information about static plugins here? |
|
Alright, thanks for the hints, I've been playing around a bit more and found this to be the minimal set of changes to get my test application linked (and the executable also runs fine on Windows): Note the use of the _LDFLAGS variable there, which resolves some more issues compared to just _LIBRARIES, it seems. I'll see if I can use this method to get a working sigrok build and report back. It's somewhat of a hack to (ab)use pkg-config instead of using the cmake facilities of course, but it's certainly a good thing to have a workaround at least for the time being. |
|
Indeed, but I can't find any built-in cmake facilities for this - does the static build work on Linux? |
|
To get minimal Pulseview built: diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee58ce2..d21b957 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -81,6 +81,7 @@ if(FORCE_QT4)
set(Qt5Core_FOUND FALSE)
else()
find_package(Qt5Core QUIET)
+ pkg_check_modules(QT5ALL REQUIRED Qt5Widgets Qt5Gui Qt5Svg)
endif()
if(Qt5Core_FOUND)
@@ -460,9 +461,7 @@ if(WIN32)
# On Windows we need to statically link the libqsvg imageformat
# plugin (and the QtSvg component) for SVG graphics/icons to work.
add_definitions(-DQT_STATICPLUGIN)
- link_directories("${QT_PLUGINS_DIR}/imageformats")
- list(APPEND PULSEVIEW_LINK_LIBS "-lqsvg")
- list(APPEND PULSEVIEW_LINK_LIBS ${QT_QTSVG_LIBRARY})
+ list(APPEND PULSEVIEW_LINK_LIBS Qt5::QSvgPlugin)
endif()
if(ANDROID)
@@ -490,6 +489,7 @@ target_link_libraries(${PROJECT_NAME} ${PULSEVIEW_LINK_LIBS})
if(WIN32)
# Pass -mwindows so that no "DOS box" opens when PulseView is started.
set_target_properties(${PROJECT_NAME} PROPERTIES LINK_FLAGS "-mwindows")
+ target_link_libraries(${PROJECT_NAME} Qt5::QWindowsIntegrationPlugin -lQt5PlatformSupport ${QT5ALL_LDFLAGS})
endif()
#===============================================================================
diff --git a/main.cpp b/main.cpp
index 0396706..1041e85 100644
--- a/main.cpp
+++ b/main.cpp
@@ -46,7 +46,8 @@
#ifdef _WIN32
// The static qsvg lib is required for SVG graphics/icons (on Windows).
#include <QtPlugin>
-Q_IMPORT_PLUGIN(qsvg)
+Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
+Q_IMPORT_PLUGIN(QSvgPlugin)
#endif
void usage()Use the mxe cmake wrapper: open app and click around: |
|
Nice, thanks! Will test the last one ASAP. |
|
With updated #1645, pkg-config libs are automatically included so the only changes required are for plugins: diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee58ce2..fc555d6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -460,9 +460,7 @@ if(WIN32)
# On Windows we need to statically link the libqsvg imageformat
# plugin (and the QtSvg component) for SVG graphics/icons to work.
add_definitions(-DQT_STATICPLUGIN)
- link_directories("${QT_PLUGINS_DIR}/imageformats")
- list(APPEND PULSEVIEW_LINK_LIBS "-lqsvg")
- list(APPEND PULSEVIEW_LINK_LIBS ${QT_QTSVG_LIBRARY})
+ list(INSERT PULSEVIEW_LINK_LIBS 0 Qt5::QSvgPlugin)
endif()
if(ANDROID)
@@ -490,6 +488,7 @@ target_link_libraries(${PROJECT_NAME} ${PULSEVIEW_LINK_LIBS})
if(WIN32)
# Pass -mwindows so that no "DOS box" opens when PulseView is started.
set_target_properties(${PROJECT_NAME} PROPERTIES LINK_FLAGS "-mwindows")
+ target_link_libraries(${PROJECT_NAME} Qt5::QWindowsIntegrationPlugin -lQt5PlatformSupport)
endif()
#===============================================================================
diff --git a/main.cpp b/main.cpp
index 0396706..fef6f6f 100644
--- a/main.cpp
+++ b/main.cpp
@@ -43,10 +43,11 @@
#include "config.h"
-#ifdef _WIN32
+#if defined(_WIN32) && defined(QT_STATICPLUGIN)
// The static qsvg lib is required for SVG graphics/icons (on Windows).
#include <QtPlugin>
-Q_IMPORT_PLUGIN(qsvg)
+Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
+Q_IMPORT_PLUGIN(QSvgPlugin)
#endif
void usage() |
|
Thanks, gave the last patch a test-run after building a completely fresh MXE from scratch as of today. Still getting a bunch of linker errors, but I'll look into it in more detail in a bit. |
|
The last patch needs #1645 to be merged, use the previous one until then. |
|
I had already tried the previous patch, yielded linker errors here too. FWIW, I'm running a minimally modified sigrok-cross-mingw script, something like this: (x.patch being one of your patches above) I tried with just "cmake" and "-DCMAKE_TOOLCHAIN_FILE=..." as well as with using "i686-w64-mingw32.static.posix-cmake", doesn't seem to make a difference. |
|
Could you post the log? I'm building it as an mxe plugin and can't replicate (see log). I don't think it matters, but I'm also using a minimal libsigrok with these options: and none of the other libs in sigrok-cross-mingw. |
|
Yeah, shouldn't make a difference in theory, but it depends on what you built inside of MXE, I think. libsigrok's configure will simply not build optional stuff if the requirements are not found, so all the above switches are optional theoretically. For reference, here's how I build fresh MXE instances (for qt5 only): Will upload a log in a few minutes. |
|
(this was with your previous patch and mine for sigrok-cross-mingw, see above) |
|
Okay, with the script I can see the Just removing the file will let the build succeed without any Qt5 issues (using your script changes, #1645 and the last pulseview changes): diff --git a/cross-compile/mingw/sigrok-cross-mingw b/cross-compile/mingw/sigrok-cross-mingw
index 8465f4a..3d0fed3 100755
--- a/cross-compile/mingw/sigrok-cross-mingw
+++ b/cross-compile/mingw/sigrok-cross-mingw
@@ -92,6 +92,7 @@ mkdir -p $PREFIX
# and c:\Python32\include have been stored in the Python32_*.tar.gz tarball.
$WGET http://www.sigrok.org/tmp/Python32_$TARGET.tar.gz -O $PREFIX/Python32.tar.gz
tar xzf $PREFIX/Python32.tar.gz -C $PREFIX
+rm $PREFIX/Python32/libs/*bz2*
# Create a dummy python3.pc file so that pkg-config finds Python 3.
mkdir -p $PREFIX/lib/pkgconfigI also skipped the |
|
I've added support for correct ordering of plugins to #1645 and now the following works: diff --git a/cross-compile/mingw/sigrok-cross-mingw b/cross-compile/mingw/sigrok-cross-mingw
index 8465f4a..27120f7 100755
--- a/cross-compile/mingw/sigrok-cross-mingw
+++ b/cross-compile/mingw/sigrok-cross-mingw
@@ -57,10 +57,11 @@ export PATH=$MXE/usr/bin:$PATH
TOOLCHAIN_TRIPLET="$TARGET-w64-mingw32.static.posix"
+CMAKE="$TOOLCHAIN_TRIPLET-cmake"
+
P="$PREFIX/lib/pkgconfig"
P2="$MXE/usr/$TOOLCHAIN_TRIPLET/lib/pkgconfig"
C="--host=$TOOLCHAIN_TRIPLET --prefix=$PREFIX CPPFLAGS=-D__printf__=__gnu_printf__"
-CM="-DCMAKE_TOOLCHAIN_FILE=$MXE/usr/$TOOLCHAIN_TRIPLET/share/cmake/mxe-conf.cmake"
L="--disable-shared --enable-static"
if [ $TARGET = "i686" ]; then
@@ -103,7 +104,7 @@ includedir=\${prefix}/include
Name: Python
Description: Python library
Version: 3.2
-Libs: -L$PREFIX/Python32/libs -lpython32
+Libs: $PREFIX/Python32/libs/libpython32.a
Cflags: -I$PREFIX/Python32/include
EOF
@@ -196,11 +197,12 @@ cd ..
# PulseView
$GIT_CLONE git://sigrok.org/pulseview
cd pulseview
+patch -p1 < ../../x.patch
if [ $DEBUG = 1 ]; then
# Allow a "DOS box" to open on Windows, it'll contain logging output.
patch -p1 < ../../pv_mwindows.patch
fi
-cmake $CM -DCMAKE_INSTALL_PREFIX:PATH=$PREFIX -DDISABLE_WERROR=y -DENABLE_TESTS=y .
+$CMAKE -DCMAKE_INSTALL_PREFIX:PATH=$PREFIX -DDISABLE_WERROR=y -DENABLE_TESTS=y .
make $PARALLEL $V
if [ $DEBUG = 1 ]; then
make install $VPulseview changes (x.patch): diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee58ce2..2fd4636 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -446,7 +446,7 @@ set(PULSEVIEW_LINK_LIBS
if(STATIC_PKGDEPS_LIBS)
link_directories(${PKGDEPS_STATIC_LIBRARY_DIRS})
- list(APPEND PULSEVIEW_LINK_LIBS ${PKGDEPS_STATIC_LIBRARIES})
+ list(APPEND PULSEVIEW_LINK_LIBS ${PKGDEPS_STATIC_LDFLAGS})
if(WIN32)
# Workaround for a MinGW linking issue.
list(APPEND PULSEVIEW_LINK_LIBS "-llzma -llcms2")
@@ -460,9 +460,13 @@ if(WIN32)
# On Windows we need to statically link the libqsvg imageformat
# plugin (and the QtSvg component) for SVG graphics/icons to work.
add_definitions(-DQT_STATICPLUGIN)
- link_directories("${QT_PLUGINS_DIR}/imageformats")
- list(APPEND PULSEVIEW_LINK_LIBS "-lqsvg")
- list(APPEND PULSEVIEW_LINK_LIBS ${QT_QTSVG_LIBRARY})
+ if(Qt5Core_FOUND)
+ list(APPEND PULSEVIEW_LINK_LIBS Qt5::QWindowsIntegrationPlugin Qt5::QSvgPlugin)
+ else()
+ link_directories("${QT_PLUGINS_DIR}/imageformats")
+ list(APPEND PULSEVIEW_LINK_LIBS "-lqsvg")
+ list(APPEND PULSEVIEW_LINK_LIBS ${QT_QTSVG_LIBRARY})
+ endif()
endif()
if(ANDROID)
diff --git a/main.cpp b/main.cpp
index 0396706..53c6343 100644
--- a/main.cpp
+++ b/main.cpp
@@ -43,11 +43,16 @@
#include "config.h"
-#ifdef _WIN32
+#if defined(_WIN32) && defined(QT_STATICPLUGIN)
// The static qsvg lib is required for SVG graphics/icons (on Windows).
#include <QtPlugin>
+#if QT_VERSION >= 0x050000
+Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
+Q_IMPORT_PLUGIN(QSvgPlugin)
+#else
Q_IMPORT_PLUGIN(qsvg)
#endif
+#endif
void usage()
{Setting |
|
@avih, the following changes and build command work, it's mostly a matter of:
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 96b66af..bc51643 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -14,7 +14,7 @@ if(BUILD_GUI)
include_directories(BEFORE uisupport)
include_directories(BEFORE qtui)
- if(STATIC)
+ if(STATIC_IMAGE_FORMAT_PLUGINS) # mxe has these as builtins
link_directories(${QT_PLUGINS_DIR}/imageformats)
set(CLIENT_LIBRARIES ${CLIENT_LIBRARIES} qjpeg qgif)
endif()
diff --git a/src/common/quassel.h b/src/common/quassel.h
index e9ed0f9..4f5d58f 100644
--- a/src/common/quassel.h
+++ b/src/common/quassel.h
@@ -25,6 +25,11 @@
#include <QLocale>
#include <QString>
+#include <QtPlugin>
+#if QT_VERSION >= 0x050000
+Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
+#endif
+
#include "abstractcliparser.h"
class QFile;
diff --git a/src/qtui/CMakeLists.txt b/src/qtui/CMakeLists.txt
index 5fee3df..bef653d 100644
--- a/src/qtui/CMakeLists.txt
+++ b/src/qtui/CMakeLists.txt
@@ -211,4 +211,4 @@ endif()
add_library(mod_qtui STATIC ${SOURCES} ${SPSRC} ${UI})
qt_use_modules(mod_qtui Core Gui Network ${QT_MODULES})
-target_link_libraries(mod_qtui mod_client mod_common mod_uisupport ${LIBS})
+target_link_libraries(mod_qtui mod_client mod_common mod_uisupport ${LIBS} Qt5::QWindowsIntegrationPlugin)
|
|
@tonytheodore thanks! and nice :) Does it also require something from #1645 ? [edit] This is hopefully unrelated, but still worth noting that I enabled subpixel antialiasing for freetype (ft disables it by default), and added harfbuzz for freetype (at (I'll probably PR the freetype subpixel AA config and the Qt5 freetype fix - once I can put everything together and confirm it also works for static cmake builds - again, it already works fine for static qmake builds). |
|
Thanks for all the help! I've finally committed a set of patches which work for me with the current setup. Full details: Some of the remaining linker errors (other than the bz2 stuff) were related to the PulseView unit tests, which can be fixed by giving them the same link libs explicitly or implicitly. |
|
@uwehermann, good to hear you got it working - some parts of this made me question whether I understand linking at all! Unfortunately, it will break with the update to Qt 5.8(#1650). The @avih the anti-aliasing support sounds like a great feature for windows users. If you have the time, can you get it to work with qmake 5.8 instead of cmake? It's pretty clear now that cmake needs to be at parity with qmake, I'm reasonably sure I can do that but getting it upstream may be a challenge. |
The patches are for freetype (config) and Qt (fix), and are unrelated to cmake or qmake, and they already work fine for qmake based projects in MXE. My original Qt patch was for 5.7.1 but it was trivial to rebase it to 5.8. I'll PR those at some point. I also have another related patch which allow env vars override for freetype rendering parameters in Qt (hintstyle and lcdfilter. while subpixel order was already supported previously in Qt with QT_SUBPIXEL_AA_TYPE). This is because Qt doesn't necessarily consider fontconfig correctly on Windows, and this was a small and easy enough patch instead of understanding how Qt interacts with fontconfig+freetype on Windows and possibly fixing it, and also allows controlling this even if fontconfig was not enabled for Qt. Changing the hintstyle to none/slight in Qt (defaults to full on Windows, none elsewhere) also has the additional benefit of enabling subpixel positioning in Qt (it's an automatic Qt thing), which really unlocks the full potential of text rendering in Qt. I'll also PR enabling hintslight by default on windows and/or these env vars overrides. Note that by default freetype is not used on windows (and so none of the above applies by default when running a Qt app), but one could enable it via
MXE would be a start. You're referring to #1645, yes? It's still not clear to me if your quassel build instructions require #1645 first, and I'm assuming yes (do correct me if I'm wrong), but it doesn't apply anymore to Qt 5.8, and I didn't try it with 5.7.1. |
Yes, the build did require #1645 but the approach of using pkg-config to supplement cmake is too flaky in the face of qt changes. For example, in 5.8, the pkg-config file for Qt5Sql no longer returns the base sql libraries (-lpq -lsybdb etc.) and their dependencies. These have been moved to plugins and the pkg-config files have no awareness of plugins. The cmake modules are aware of plugins, but only at a single level and don't have awareness of the intermediate libraries (Qt5EventDispatcherSupport Qt5AccessibilitySupport Qt5FontDatabaseSupport Qt5ThemeSupport etc.) and their transitive deps. All the required metadata is in the qmake prl and pri files, it's "simply" a matter of processing these in a robust way;) |
We currently need to (ab)use pkg-config to get all the required
Qt5 static linking dependencies right, since this doesn't yet
work properly in MXE's cmake.
We use ${PKGDEPS_STATIC_LDFLAGS} instead of ${PKGDEPS_STATIC_LIBRARIES}
to avoid some linker issues related to libbz2.
We need to add Qt5::QSvgPlugin, Qt5::QWindowsIntegrationPlugin,
Qt5PlatformSupport and all the Qt5 libs and their dependencies to
the link libraries list (for both PulseView and the unit tests).
In one of the source code files we need to explicitly list all
static Qt plugins via Q_IMPORT_PLUGIN to make static builds work,
which is currently QWindowsIntegrationPlugin and QSvgPlugin.
We're only focusing on having a working Qt5 build for Windows,
as we no longer need to or want to support Qt4 there.
Details:
mxe/mxe#1642
Thanks to Tony Theodore for the help!
This should also fix bug #871, since we're now building with Qt >= 5.6
which has high-DPI support in general.
Tested via manual specification (might need further changes, though):
set QT_SCALE_FACTOR=2
pulseview.exe
We currently need to (ab)use pkg-config to get all the required
Qt5 static linking dependencies right, since this doesn't yet
work properly in MXE's cmake.
We use ${PKGDEPS_STATIC_LDFLAGS} instead of ${PKGDEPS_STATIC_LIBRARIES}
to avoid some linker issues related to libbz2.
We need to add Qt5::QSvgPlugin, Qt5::QWindowsIntegrationPlugin,
Qt5PlatformSupport and all the Qt5 libs and their dependencies to
the link libraries list (for both PulseView and the unit tests).
In one of the source code files we need to explicitly list all
static Qt plugins via Q_IMPORT_PLUGIN to make static builds work,
which is currently QWindowsIntegrationPlugin and QSvgPlugin.
We're only focusing on having a working Qt5 build for Windows,
as we no longer need to or want to support Qt4 there.
Details:
mxe/mxe#1642
Thanks to Tony Theodore for the help!
This should also fix bug #871, since we're now building with Qt >= 5.6
which has high-DPI support in general.
Tested via manual specification (might need further changes, though):
set QT_SCALE_FACTOR=2
pulseview.exe
This avoids a libbz2 linking issue later on in the PulseView build. Details: mxe/mxe#1642 Thanks to Tony Theodore for the help!
|
After going through the discussion here I'm now linking my app like this:
But I get a lot of stuff like this: I also have: And
Am I still missing something? |
|
That's roughly where I got stuck last time - the cmake modules seem to have no support for the intermediate libraries and their dependencies (Qt5EventDispatcherSupport Qt5AccessibilitySupport Qt5FontDatabaseSupport Qt5ThemeSupport etc.) To make it work manually, you can browse for likely libs: or grep through qmake's .pri/.prl files: to find some linker options. What project are you building and do you know upfront what plugins it's using? |
|
I'm working on this project: https://github.com/juzzlin/Heimer I already switched to qmake for Windows build so that I can make the NSIS installer. The original idea was to use CPack to create NSIS installer and it already worked except that the binary didn't work due to this static lib mess :) I might try to manually link to the *Support libraries like you suggested. The application is just a traditional QGraphicsView application without anything special currently. It depends on QtWidgets and QtXml. |
|
I think |
|
There are definitely some progress made. Trying to build Qt5 application generated in Qt Creator using template "Qt Widgets Application" with current mxe master branch (CMake 3.15.4, Qt 5.14.0) results in just few linking errors: My words are such optimistic because trying to build a little more complex app (i.e. with more dependencies) gives same result. |
|
Yes, that's MXE fault! I've just installed missing dependencies into MXE, i.e packages |
|
... but application using QtSerialPort fails to link: |
|
... and problem being solved by adding |
|
I'm sure similar failure with QtSerialPort may happen with any other Qt Add-On (i.e. module not being part of qtbase), and applicable only to static Qt linkage (although I didn't checked shared linkage). For essential modules MXE |
|
I found root cause of failure. It's a qtbase |
That isn't actually a fix, it's a workaround by manually hardcoding the required libs. The last time I looked at it a few months ago, the platform plugins were being handled correctly, but the transitive dependencies were incorrectly ordered. I'll try to have another look on the weekend. |
It isn't platform plugins who caused build fail, but missing package dependencies and another Qt packages (outside of
That fix/workaround (limited to |
|
Confirming that Qt shared build works too (provided that application deployed properly, which mostly can be automated using one of |
TL;DR: MXE+Qt5+cmake doesn't seem to work.
Hi, I've been trying for quite a while to make sigrok (www.sigrok.org) Windows packages using Qt5 + MXE, without any success unfortunately (our current packages use Qt4, which has also been a challenge to implement as well, but that's somewhat working at least).
For our purposes we're depending on a number of specific things that need to work together:
(and static builds of everything else in MXE and outside MXE, of course)
Within Qt5 we need the following: Qt5Core, Qt5Gui, Qt5Svg and various static plugins (directly or indirectly) such as qsvg, QWindowsIntegrationPlugin and such.
I've spent countless days trying to get a successful build, but I didn't get anywhere near a successful build that will also work at runtime.
So my question is whether I'm doing something wrong or whether there are bugs in MXE e.g. regarding i686-w64-mingw32.static.posix+Qt5+cmake that would prevent this from working?
In order to get something reproducible that demonstrates the problem without too many dependencies on all kinds of other stuff we do in sigrok, I've created this demo repo here:
https://github.com/uwehermann/qt5helloworld
It contains a simple project that I generated in qtcreator on Linux which basically just shows an empty window. I added the simplest-possible CMakeLists.txt file for buiding it, and two shell scripts to demonstrate exactly how I'm building.
I've tried all kinds of things in CMakeLists.txt, the source code itself, random MXE patching, nothing has worked sufficiently well so far.
Can someone please verify that the repo I provided does indeed build fine on Linux and doesn't build with MXE?
If yes, any patches against MXE and/or that repo to make this simple project build and run successfully would be really appreciated. It would at least be a basis for further work (I'm pretty sure the static Qt5 plugins will be the next major issue causing headaches after that).
Please let me know if you need any more info. Thanks!
The text was updated successfully, but these errors were encountered: