Package Details: mingw-w64-qt5-base 5.15.16+kde+r130-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-qt5-base.git (read-only, click to copy)
Package Base: mingw-w64-qt5-base
Description: A cross-platform application and UI framework, native OpenGL backend (mingw-w64)
Upstream URL: https://www.qt.io/
Licenses: custom, GPL3, LGPL3, FDL
Groups: mingw-w64-qt5
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 21
Popularity: 0.025120
First Submitted: 2016-08-30 21:28 (UTC)
Last Updated: 2024-11-25 20:54 (UTC)

Sources (33)

Pinned Comments

Martchus commented on 2023-06-07 19:48 (UTC)

Who flagged this package (or wants to flag it): The KDE patch branch doesn't seem rebased yet and the regular qt5-base package has not been updated as well. Since this package is using the KDE patch branch I'm going to wait for them to rebase. You generally don't need to flag the package as I'm subscribed to relevant Qt mailing lists anyways.

Martchus commented on 2021-04-14 10:08 (UTC)

I've been updating this package and some further modules to use patches from KDE's fork. This is in accordance with the native Qt packages. As far as I know KDE's fork is not tagging releases. However, I will not pick up every single new commit on their branch but only update the package when it is worth it. Only flag the package as out-of-date if there are patches on their branch which are generally very important.

Martchus commented on 2020-09-13 11:42 (UTC)

Notes regarding 5.15.1 update

  • With this update I finally splitted all static libraries from further Qt repositories into their own packages as well. So now there's not only mingw-w64-qt5-base-static but also mingw-w64-qt5-svg-static, mingw-w64-qt5-declarative-static and so on. The static version is still sharing files with the shared version and as such depends on the shared packages. However, this change allows to avoid building all the static libraries if only shared libraries are required. If you've so far used static libraries from further Qt modules be sure to install the additional *-static packages.
  • Otherwise there were not much build system changes on the Qt side so I don't think this update broke much.
  • As stated in the sticky comment I'm thinking about Qt 6 packaging but this also means I'm not going to take much effort to address any outstanding bugs/limitations for the Qt 5 packages anymore (broken ANGLE build, build Qt WebEngine, …).
  • This is the last official release of the 5.x. Let's see whether further updates for the 5.x branch will be made available by the community. If the regular qt5-base packages picks up such commits I could update this package here as well.

Martchus commented on 2018-05-29 08:29 (UTC) (edited on 2020-01-31 13:46 (UTC) by Martchus)

Before upgrading, be sure to remove the old version of the package from your system. Preferably, build the package in a clean chroot using makechrootpkg.

Also, please read the other comments and issues on GitHub for known bugs and limitations.

There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff, https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff

Martchus commented on 2018-03-11 20:19 (UTC) (edited on 2020-09-13 11:45 (UTC) by Martchus)

@theone74 It is currently not possible to use the MariaDB plugin with the static version of Qt because mariadb-connector-c comes with its own pthread implementation which has conflicting symbols with the pthread library Qt uses. Since some PostgreSQL update the same is true for the PostgreSQL plugin.

So you have to disable the plugin. When using CMake, plugins are not be automatically added so you should not run into the issue by default. When using qmake you need to disable the plugin manually, eg. you can add the following arguments to enable only the plugins which actually work:

CONFIG+=no_smart_library_merge QTPLUGIN.sqldrivers=qsqlite QTPLUGIN.sqldrivers+=qsqlodbc CONFIG+=static

(https://github.com/Martchus/PKGBUILDs/blob/master/qt5-tools/mingw-w64-static/PKGBUILD#L45)

Martchus commented on 2016-07-10 19:47 (UTC) (edited on 2020-01-31 13:47 (UTC) by Martchus)

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs

Patches for this package are managed at: https://github.com/Martchus/qtbase/tree/5.11.0-mingw-w64
if you like to contribute to patches, read this: https://github.com/Martchus/PKGBUILDs/#contributing-to-patches

If you would like to contribute, here is a list of known bugs and things needing improvement:

  • The linker library search paths for applications which need to be build for the host architecture aren't set correctly. Hence those paths are currently set manually which is quite hacky. Affected packages are mingw-w64-qt5-declarative and mingw-w64-qt5-tools and (also the apple-darwin versions).
  • Compiling QtAV using the ANGLE version doesn't work. I don't know whether other applications/libs using OpenGL via Qt are also affected but it is very likely.
  • Updating mingw-w64-qt5-webkit to ng version.
  • See also https://github.com/Martchus/PKGBUILDs/issues

Also note the comments about the different variants inside the PKGBUILD itself.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

Martchus commented on 2017-08-25 16:42 (UTC) (edited on 2017-08-25 16:45 (UTC) by Martchus)

@hein09 I found a workaround. See my previous comment for an answer to your last question and what the related problems are (if you haven't read it yet). It seems the issue that qmake is messing dependency cycle between freetype2 and harfbuzz can be easily worked around by simply adding `no_smart_library_merge` to the config. No need to recompile anything. Maybe I better keep 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch for CMake. So the following works for me: ``` pacman -Syu qt5-examples cd some/empty/directory x86_64-w64-mingw32-qmake-qt5 CONFIG+=static CONFIG+=no_smart_library_merge /usr/share/doc/qt/examples/widgets/mainwindows make -j4 wine mainwindow/release/mainwindow.exe ``` No linker errors. And when applying https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f `mainwindow.exe` even has the windows platform plugin built-in. Only drawback is that the linker line is now quite long (but g++ seems to handle it without problems). (Instead of rebuilding everything, you can also do the changes of https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f in your local installation. I'll add the patch with the next update.)

Martchus commented on 2017-08-25 15:39 (UTC) (edited on 2017-08-25 16:48 (UTC) by Martchus)

@hein09 I don't remember the purpose so I'll just drop it in the next update. However, when something explicitly supports Windows, this might not necessarily include cross compilation with mingw-w64 (which is not supported by upstream). > What should trigger this automatic adding? If you're using CMake, nothing will pull those dependencies if you omitted patch 0023-Allow-usage-of-static-version-with-CMake.patch. (BTW, this monster patch will be spitted in next update, see https://github.com/Martchus/qtbase/commits/5.9.1-mingw-w64) If you're using qmake, some qmake internal magic triggers adding those dependencies. However, it seems to mess things up under certain conditions. At least the cyclic dependency between harfbuzz and freetype2 is not handled correctly. Hence I disabled this when building static libraries (see 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch). However, when building/linking the final application it is still enabled (unless you use `CONFIG+=staticlib`). This way the static library dependencies are at least preserved for CMake so building a statically linked application using CMake works. When building with qmake you'll unfortunately either get linker errors about freetype2/harfbuzz (if you don't add `CONFIG+=staticlib`) or get linker errors about other missing dependencies not explicitly mentioned in the mkspec (iconv, but also dependencies of the plugins). Those problems with qmake are currently not preventing mingw-w64-qt5-tools to build because linking against static plugins with qmake is broken anyways and hence the freetype2/harfbuzz issue does not seem to occur. BTW: If you're wondering why it links against pcre *and* pcre2, the reason is that Qt recently switched to version 2 but pcre is still pulled by harfbuzz for glib2. To summarize: The static variant only works with CMake correctly. 1. Linking against static plugins with qmake needs to be fixed. It is currently simply not done. This is caused by 0022-Merge-shared-and-static-library-trees.patch. Fixing it should be quite easy: https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f 2. But this leads to the next problem. The dependency cycle between freetype2 and harfbuzz must be handled correctly by qmake. The patch 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch is only sufficient for CMake. To make qmake work when 1. has been fixed, qmake must be improved to handle the dependency cycle between freetype2 and harfbuzz. So I'm not sure why iconv isn't added in your case. It should be if your config doesn't contain `staticlib` which should not be the case by default. But if you want to link against static plugins (which is likely the case when doing a static build) you're currently not coming very far with qmake anyways.

sgsaenger commented on 2017-08-24 10:13 (UTC)

@Martchus What was the purpose of this patch? (0020) As far as i understand it it just disabled taking the gcc-path in the toolchain.prf file, which explicitely supports windows as a platform (seems kind of self-defeating?) `-liconv` is indeed the last entry in `Qt5Core.static.prl`. Then the problem seems to be the automatic adding, which is just not performed. I also get undefined references for libQt5Widgets.a(qwindows{vista|xp}style.o) and libQt5Gui.a(qopenglpaintengine). What should trigger this automatic adding? (and should i move this discussion to the static AUR-package?)

Martchus commented on 2017-08-15 17:28 (UTC) (edited on 2017-08-15 17:30 (UTC) by Martchus)

@hein09 Not sure about 0020-Disable-determing-default-include-and-lib-dirs-at-qm.patch. It can likely be removed but I would have to test it first. About iconv: I'm actually not sure which libs need to be specified explicitly in the mkspec and which are added automatically by the configure script. Eg. cyclic dependency between freetype2 and harfbuzz would not be resolved correctly without doing it explicitly in the mkspec. However, iconv is added automatically - at least it works here. Does `/usr/x86_64-w64-mingw32/lib/Qt5Core.static.prl` contain the library? In my case `-liconv` is the last library in `QMAKE_PRL_LIBS`. And it also seems to be picked up - at least I'm not getting linker errors. But adding iconv explicitly would not hurt, too. So if it is causing trouble for you, I can add it. I guess the explicitly added pcre2 would not be required, too. At least my QMAKE_PRL_LIBS contains it twice.

sgsaenger commented on 2017-08-15 11:40 (UTC)

Is patch 0020 (still) necessary? Also, static linking against Qt (sometimes?) needs '-liconv', could this be added to the mkspec?

adsun commented on 2017-08-06 23:23 (UTC)

Okay, so doing the clean chroot successfully built the package. Thanks!

adsun commented on 2017-08-05 23:20 (UTC)

No, I did not apply custom modifications. However, I did not use a chroot. Both mingw-w64 openssl versions are installed.

Martchus commented on 2017-08-05 21:47 (UTC)

@adsun As the package build here, I have to ask: Did you apply any custom modifications to the PKGBUILD? Do you build in a clean chroot? (If not, what packages are installed?) From the error I would say -lcrypt32 is missing on the linker line. However, it is present.

adsun commented on 2017-08-05 17:57 (UTC)

Some undefined references in openssl linking. https://gist.github.com/Adsun701/8569eb5e94bc0d7cd314ac56e1b86cf6 Any way to fix this?

Martchus commented on 2017-07-06 21:52 (UTC) (edited on 2017-07-06 21:54 (UTC) by Martchus)

Updated to 5.9.1 * OpenSSL - Use of old OpenSSL 1.0 is still required. - Static build links now (statically) against OpenSSL rather than loading OpenSSL at runtime. This makes more sense as it allows to distribute everything in a single binary. Unfortunately this will lead to symbol clash when trying to link an application against OpenSSL 1.1. - Dynamic build still doesn't link against OpenSSL. OpenSSL is loaded at runtime instead (same as before) using the following search order: ssleay32.dll/libeay32.dll, libssl-10.dll/libcrypto-10.dll, libssl-8.dll/libcrypto-8.dll, libssl-7.dll/libcrypto-7.dll * The patch 0023-Allow-usage-of-static-version-with-CMake.patch has been improved so static-only modules can be found under regular name. Additionally, it is now possible to use the static variant via CMake by just setting USE_STATIC_QT_BY_DEFAULT. Then the static variant is used by default without the need of using 'Static'-prefix. - eg. https://github.com/Martchus/Qt-CMake-HelloWorld/blob/mingw-w64-static-by-default/CMakeLists.txt - prefixed version which allows using both variants in the same project is still possible: https://github.com/Martchus/Qt-CMake-HelloWorld/blob/mingw-w64-static/CMakeLists.txt * There is no update for Qt WebKit, but I suppose it wouldn't be worth the rebuilding effort anyways. Instead I'll try updating to ng version.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »