Re: [Interest] Android Build fails with Gradle qtGradlePluginType
Hi, the packaging you mentioned (and that I maintain) worked for me last time I tried. Be sure to use Java 17 to workaround https://bugreports.qt.io/browse/ QTBUG-119223 (although the error message in your case looks a bit different). Otherwise you probably need to find out how to get a more verbose error message. Maybe you can also share your code with us so we can spot possible mistakes. Example build commands I used to build one of my apps using the mentioned packaging (contains "export …" command to use Java 17): https://github.com/Martchus/passwordmanager?tab=readme-ov-file#concrete-example-of-3-for-building-an-android-apk-under-arch-linux You can also inspect the other files in that repo to see what you might be missing but the app unfortunately requires Kirigami so you won't be able to build it. So you probably better checkout one of the Qt examples that also come with Android support and cross-check whether you can build those (using similar commands). Here is also an example CMake preset to use the packaging (which makes it very convenient to use): https://github.com/Martchus/cpp-utilities/blob/ 9a1a4fb80bd9a3feb841507503c479a2195ded54/CMakePresets.json#L379 Best Regards Marius signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tweaking a static build of Qt 6 for Windows
When it comes to building a static version of Qt itself then you need to adjust things on CMake-level, indeed. When your project is still using qmake, then qmake's "mkspecs" are supposedly still relevant for building your project. (I cannot say much about that because I'm using CMake in all my projects anyways.) Note that my experience with Qt6/CMake was actually much better compared to Qt5/qmake. I had much less additional patching to do to make it work in my build environment. However, there were still a few places that needed patching. This branch contains patches that I came up with for the mingw-w64 and GNU/Linux targets and a build environment where also most of Qt's own dependencies are provided as static libraries: https://github.com/Martchus/qtbase/commits/6.4.2-mingw-w64 (Maybe you need to do things differently for the targets and build environment you're concerned with. I'm merely sharing those patches as they show the interesting "spots" in Qt's code. Additionally, not all patches on that branch are related to making a static build. There are also other branches in that repo based on earlier Qt releases. If you go back to Qt5 you'll see how it looked for me when Qt was still built with qmake.) Best Regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] qwindows.dll additional dependencies
To my knowledge these libraries are Windows API sets and are provided by Windows itself. So they should supposedly *not* be distributed with your application. You can read more about it on https://learn.microsoft.com/en-us/ windows/win32/apiindex/windows-apisets?source=recommendations and https://www.geoffchappell.com/studies/windows/win32/apisetschema/index.htm if you're interested in the details. Best Regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Official linuxdeployqt ?
Am Freitag, 5. August 2022, 18:16:53 CEST schrieb Scott Bloom: > Unfortunately both of these solutions (runtime dependencies and static > build) only solve the staticly bound dynamically loaded DLLs That's not true. A static Qt build also has plugins in form of static libraries and you'll have to decide when building/linking your app which plugins to link against (which is not a big deal). I haven't used `GET_RUNTIME_DEPENDENCIES` myself but I would assume if you specify all plugin targets you need as `MODULES` it'll take those dependencies into account as well. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Minimal glibc version for Qt 5.15.9
Hi, I don't know the minimum required glibc version of Qt. I recently compiled Qt 6.3.0 against glibc 2.26 (at least qtbase, qtdeclarative, qtwayland and a few more repos) and it worked just fine. Likely it builds against even lower versions of glibc as well. I suppose you'll have to test it yourself. Since you've mentioned Ubuntu 18.04 specifically: I've already tested my build on that particular OS and they worked, as well as on openSUSE Leap 15.3 and an up-to-date Arch Linux system. So it is certainly possible to support that OS using the latest Qt 6 release and surely the same applies to Qt 5. Note that if you build Qt (or any other library) against a certain glibc version than that is the minimum required glibc version of that specific build. Additionally, you also need to build all dependencies in your stack (e.g. also dependencies of Qt itself, and the dependencies of that dependencies and so on) against that older glibc version. Of course that doesn't count for dependencies used only at build time, e.g. I could use Arch Linux's recent LLVM/Clang build to link tools from qttools against (in a quite hacky way, but it worked). (Further more obvious examples of build-only tools are of course binutils, CMake, Meson and autotools. However, GCC needs to be built against the older glibc as it contains libstdc++ which is required at runtime.) By the way, these are the build scripts I used to conduct builds against glibc 2.26 (under Arch Linux): https://github.com/Martchus/PKGBUILDs#static-gnulinux-libraries= Best Regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.3.0 Android and SSL feature issue
Hi, I've seen these kinds of error messages a lot also when not cross-compiling. They always occurred after upgrading Qt 6.x.x packages (e.g. provided by TW), especially when Qt 6 was still in the alpha/beta phase. I could always resolve it by simply adapting my CMake config accordingly (or simply starting with a clean build directory from scratch). I don't use official binaries but my own Qt 6.3.0 builds still have contain e.g. "libplugins_tls_qopensslbackend_arm64-v8a.so" and "libplugins_tls_qcertonlybackend_arm64-v8a.so" without having to alter any build flags. So I don't think TLS support became generally unavailable under Android. Best regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Configuring Qt's built-in freetype ?
Am Samstag, 1. Januar 2022, 17:23:22 CET schrieb Jean-Michaël Celerier: > Yet I still get non-subpixel AA when rendering so there may be a bit more > to that issue... Just to rule out a simple mistake: Be aware that Qt is *not* using FreeType2 under Windows by default (also if Qt was compiled with FreeType2 support) so any changes to the FreeType2 config make no difference by default. This is especially notable when trying to use WOFF which thus doesn't work by default. See https://github.com/Martchus/qtforkawesome#providing-the-font-file which also explains how to configure the Windows platform plugin to use FreeType2. Best Regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt6–QtMultimedia – MinGW Support
Am Montag, 15. November 2021, 14:59:58 CET schrieb Alexey Pavlov: > Mingw-w64 have added libraries for WMF recently, it not in release version > yet. You need use mingw-w64 runtime from git. > Great. Since I personally don't need it right now I'll just wait for the next mingw-w64 release but I suppose building against the latest mingw-w64 from Git is currently the best option then. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt6–QtMultimedia – MinGW Support
Hi, I've already built Qt 6 Multimedia with the a recent version of mingw-w64 (9.0.0) and GCC (11.2.0) but the resulting build was rather limited. In fact I've got nothing: ``` Qt Multimedia: ALSA ... no GStreamer 1.0 .. no Video for Linux no PulseAudio . no MMRenderer . no AVFoundation ... no Windows Media Foundation ... no ``` The problem is ``` -- Could NOT find WMF (missing: WMF_MF_LIBRARY WMF_MFUUID_LIBRARY WMF_MFPLAT_LIBRARY WMF_MFCORE_LIBRARY WMF_PROPSYS_LIBRARY) ``` and I suppose that's really a limitation of mingw-w64 at this point. Unfortunately with Qt 6 WMF is the only remaining backend - except for GStreamer which I suppose one could also use as an alternative. At least the build system was looking for it: ``` -- Could NOT find GStreamer (missing: GStreamer_Core_FOUND GStreamer_Base_FOUND GStreamer_Audio_FOUND GStreamer_Video_FOUND ``` I haven't installed GStreamer libs in my build env but if I actually needed Qt Multimedia I'd try that. Building GStreamer libs and its dependencies for mingw-w64 generally works (maybe not static linking, though). Maybe there's also an experimental version of mingw-w64 available which has support for WMF. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Detecting system power events
I'm not aware of a cross-platform way. On a systemd-based system you can easily use its D-Bus interface via Qt DBus: https://www.freedesktop.org/ software/systemd/man/org.freedesktop.login1.html#Signals You can check https://github.com/Martchus/syncthingtray/blob/master/connector/ syncthingservice.cpp for an example. However, I'd also be interested in a cross-platform solution or at least some implementations of this for further platforms within the context of a Qt application. Under Windows it is likely just some WinAPI function but I haven't taken the time to look into it. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Provide a Means to Make Static Builds of Qt 6.1 for Android, macOS, Windows and GNU/Linux
> However, configuring and building Qt on Microsoft Windows on a Windows > host with either MinGW or MSVC has been impossible. I did it in the past and it is doable. However, I must also say that Windows is not my preferred platform for development. So for years I'm now conducting my Windows builds also on GNU/Linux, specifically Arch Linux where I maintain packages for cross compilation including static variants: https://aur.archlinux.org/packages/?K=mingw-w64-qt5 https://aur.archlinux.org/packages/?K=mingw-w64-qt6 I spend some effort so static linking works also for Qt's dependencies so that the final executable only depends on libraries provided by Windows itself. However, I must also say that this kind of cross compilation is not supported by upstream. > I would like to have virtual machines or Docker containers that allow > me to build Qt statically for all prior mentioned platforms. If it's > possible to use coin's scripts locally instead, please tell me how. I personally just use an Arch Linux machine directly but it would of course be possible to use Docker (like https://github.com/mdimura/docker-mingw-arch). Of course you can also just use the Arch PKGBUILDs as a template to create your own build scripts and just run them under any distribution. There's of course also https://github.com/mxe/mxe which also allows to make a static Qt build. I suppose they lack Qt 6 builds, though. I'm also not sure whether there's a binary repository (at least provided by some community member). For native compilation under Windows MSYS2 is also an option. Not sure how well their static variants work, though. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Configuring Qt's built-in freetype ?
Hi, I'm also using Arch and that's how they configured their FreeType2 build: https://github.com/archlinux/svntogit-packages/tree/packages/freetype2/trunk There are indeed some patches which might be an improvement. They also build with Harfbuzz support so its configuration might make a difference as well: https://github.com/archlinux/svntogit-packages/blob/packages/harfbuzz/trunk/ PKGBUILD I don't know whether you can influence the configuration of the bundled FreeType2 without patching. I personally simply configure Qt to use the system-provided library. For instance I also conduct my Windows builds under Arch for which I'm using my custom FreeType2 build in form of the `mingw-w64-freetype2` package. I try to configure the `mingw-w64-freetype2` package as close as possible to the regular `freetype2` package: https://aur.archlinux.org/packages/mingw-w64-freetype2 I suppose using your own FreeType2 build should work under any build environment as long as you install it somewhere Qt can find it. Note that the runtime configuration might also make a difference. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Require a qt_finalize_target() call in CMake user projects that use a static Qt
> Is your concern about the plugins packages being automatically found and > targets are automatically created (so that find_package is run at all), or > that they get linked to the final executable / shared library? I have generally no problem with targets being made available. However, if it means installing e.g. PostgreSQL in the build environment only to find a dependency of a plugin I don't want to link against anyways that might be a bit anoying. Nevertheless, I am mainly concerned about which plugins my final executable / shared library is linked against. > And is it about generic qt plugins and/or qml plugins? > qml plugins are not linked in by default From my user's point of view I don't make a difference. I don't remember exactly the problem with the plugins included without QT_SKIP_AUTO_QML_PLUGIN_INCLUSION. Maybe it wasn't really that they would have been linked against but just the CMake error about the missing PostgreSQL library. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Require a qt_finalize_target() call in CMake user projects that use a static Qt
Hi, to me the most important point is that I can still stay in control over which plugins are linked against and which not. At best I can turn off pulling plugins automatically completely to avoid bloating my applications and keep my own build system logic for deciding what plugins are needed. I must say that Qt 6 made this harder (in contrast to my heavily patched Qt 5 version). I'm not quite sure how to disable pulling plugins automatically and without https://github.com/Martchus/qtutilities/commit/ 7183ec501c90bfc38538fd7a810533b8a8a78cff Qt's CMake modules pulled in tons of unwanted plugins automatically. It is problematic that Qt 6 (and I suppose also recent Qt 5 versions) seemed to introduce new features regarding static plugins in CMake but the documentation wasn't extended, e.g. https://doc.qt.io/qt-6/plugins-howto.html#static-plugins looks is still only covering qmake. I have already found https://doc.qt.io/qt-6/qt-import-plugins.html but it doesn't show how to disable the automatic inclusion completely and the variable `QT_SKIP_AUTO_QML_PLUGIN_INCLUSION` I've had to use in the mentioned commit wasn't explained at all. To give you feedback on `qt_finalize_target()`: I would have no problem with an extra call and requiring an up-to-date CMake installation but don't forget to update the documentation and keep the use case of linking against plugins manually in mind. By the way, thanks for making this part of Qt's build system better! I've mentioned that I had to patch Qt 5 a lot (so it can cope with all static dependencies correctly when using CMake) and with Qt 6 all of this is not necessary anymore. So despite the mentioned problems that's actually already a huge improvement. Best Regards Marius ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QPA display system query ?
Am Dienstag, 19. Januar 2021, 05:13:13 CET schrieb Nicholas Yue:
> So I have to mimic the deployment as best as I can with regards to the QPA
> for display as that done in windowsdeployqt and macdeployqt so I have
> something like the following
>
> install(FILES
> ${QT_INSTALL_PLUGINS}/platforms/libqxcb.so
> DESTINATION
> bin/platforms
> )
>
I'd actually bundle the whole platforms directory or at least the Wayland
plugin as well. Some users of your app will use X11 and some will use Wayland.
For special purposes the other platform plugins can be interesting as well.
There is not "one GUI" on GNU/Linux. That's also why it makes sense that this
code is build in form of plugins in the first place.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to use Qt6::qmake ?
Hi, Qt's CMake modules should already make most paths available. I came up with the following approach to support Qt 5 and Qt 6: https://github.com/Martchus/ qtutilities/blob/5960c215586cf0ca777a511c6f0830c1c63ddaa8/cmake/modules/ QtLinkage.cmake#L124 It works at least for QT_INSTALL_TRANSLATIONS. Maybe it needed to be tweaked for other variables. This function also shows how to get the location of the qmake binary if you really need it after all. I'd also suggest to use the CMake modules Qt provides for using Linguist. This has already worked with Qt 5 and continues to work with Qt 6. When cross- compiling you currently need a workaround, though: https://github.com/ Martchus/qtutilities/blob/5960c215586cf0ca777a511c6f0830c1c63ddaa8/cmake/ modules/QtConfig.cmake#L303 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Where does libGL get changed to absolute and how to stop?
Am Freitag, 15. November 2019, 20:07:59 CET schrieb John Cary: > On 11/15/19 10:05 AM, Marius Kittler wrote: > > As far as I know this is done within `defineTest(qtConfResolveLibs)` in > > `qtbase/mkspecs/features/qt_configure.prf`. Not sure how to disable this > > except from patching the function. I also needed to patch it for my > > mingw-w64 builds. > > Could you share your patch? > My patch doesn't revert the library resolving. I've just modified it so my static builds don't link against shared libraries: https://github.com/ Martchus/qtbase/commit/51a0ac0ff3a726f88af9e8cd472779b33117d304 That's likely not useful for you. > > Considering the code it seems to take `-L` flags into account. So maybe > > you > > can workaround the problem by using `-L` . Or just specify the full patch > > yourself. (I assume your problem is that the library is resolved to the > > wrong full path but using full paths in general would work.) > > I put in absolute paths for QMAKE_LIBS_OPENGL, and then at the end of > configuration, > my debug statements print out the correct value. However, this > generates a file, >qtbase/src/gui/qtgui-config.pri > in which I find >QMAKE_LIBS_OPENGL = /lib64/libGL.so > and the build creates a largely redundant >qtbase/mkspecs/modules-inst/qt_lib_gui_private.pri > also containing the wrong information, and the build > still links in the system /lib64/libGL.so. > > So then I comment out that line in qtbase/src/gui/qtgui-config.pri > before starting the build. The second file, > is now correct, and the build proceeds correctly. > > So it seems that it comes down to an incorrectly generated > qtbase/src/gui/qtgui-config.pri, which I can fix post-facto, but I think > there > must be a better fix. Perhaps your patch? Maybe the value is overridden by the mkspec, e.g. by the assignment in `qtbase/mkspecs/common/linux.conf` (or whatever file is relevant for your platform). So you could try to patch this file to your needs. Otherwise I doubt I can help you much further. Sometimes I also just give up and apply some `sed` commands on the generated files. (The `qmake_all` target is useful for that.) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Where does libGL get changed to absolute and how to stop?
As far as I know this is done within `defineTest(qtConfResolveLibs)` in `qtbase/mkspecs/features/qt_configure.prf`. Not sure how to disable this except from patching the function. I also needed to patch it for my mingw-w64 builds. Considering the code it seems to take `-L` flags into account. So maybe you can workaround the problem by using `-L` . Or just specify the full patch yourself. (I assume your problem is that the library is resolved to the wrong full path but using full paths in general would work.) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] No access to MySql and MariaDB databases with Qt
> I tried to manually build the MySQL driver but failed because configure not > only looks for libmysql.* but also for a config.win32 (why). I use the following patch for my builds: https://github.com/Martchus/ PKGBUILDs/blob/master/qt5-base/mingw-w64/0013-Fix-linking-against-shared- static-MariaDB.patch That works (the resulting package contains sqldrivers/qsqlmysql.dll). Note that the PostgreSQL needed a similar patch in my case. The only problem left is that it is currently not possible to use the static build of the MariaDB and Qt because mariadb-connector-c comes with its own pthread implementation which has conflicting symbols with the pthread library Qt uses. Am Freitag, 11. Oktober 2019, 10:27:47 CEST schrieb helmut.muel...@gmail.com: > Recently the Bug "MySQL plugin binaries are in commercial packages" > https://bugreports.qt.io/browse/QTBUG-76081 was closed. > > > This means that (starting with Qt-5.12.3, I think) it is not possible to > access MySQL or MariaDB databases with LGPL or commercial Qt versions. > > > I am using LGPL Qt. To avoid licensing problems I used the QtSQL plugin for > MySQL but replaced the MySQL libmysql.dll with libmariadb.dll (by renaming > the latter). > > > This does not work anymore because there is no sqldrivers/qsqlmysql.dll in > the binary LGPL distributions. > > > I tried to manually build the MySQL driver but failed because configure not > only looks for libmysql.* but also for a config.win32 (why). > > > Any ideas or hints for this? > > > Helmut > > > PS: The current Qt documentation does not mention the problems with MySQL. > > > PPS: Anybody out there looked at libdrizzle or libdrizzle-redux as an > alternative to qsqlmysql? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
