Package Details: mingw-w64-qt5-base 5.15.2-1

Git Clone URL: (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:
Licenses: custom, GPL3, LGPL3, FDL
Groups: mingw-w64-qt5
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 19
Popularity: 0.000086
First Submitted: 2016-08-30 21:28
Last Updated: 2020-11-21 15:59

Sources (32)

Pinned Comments

Martchus commented on 2020-09-13 11:42

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 2020-06-09 10:33

Notes regarding Qt 6 packaging

I plan to package Qt 6 as well (see for a WIP version), so here are the changes I expect I'll have to make:

  1. The mingw-w64-qt5-* packages stay mainly as-is.
    1. Of course I'll be updating the patch version. If a community fork for minor version updates is created and picked up by the regular qt5-* packages it would make sense to do the same for mingw-w64-qt5-* packages.
    2. As a "final improvement" for the Qt 5 packaging I could also apply the shared vs. static splitting for all modules. Currently it is a bit weird to have a separate *-static package for the base repository but not for other repositories.
    3. ANGLE seems to be completely abandoned by Qt 6 in favor of platform-specific backends. That means I'm not going to take any effort anymore in fixing the currently broken ANGLE variant.
  2. I'll create mingw-w64-qt6-* packages for Qt 6.
    1. CMake will be the only supported build system for building Qt itself so I'll switch to that.
    2. All "host tools" need to come from the regular qt6-* packages. I consider that an improvement because it takes out complexity from the build system and also avoids redundancy. It is also more consistent with other packages, e.g. if some package needs Python to generate something during the build we also don't try to bootstrap a minimal version of Python during the build but instead simply depend on the python package.
      1. That also affects qmake. When I understand it correctly, that means all qmake-based projects will need to depend on the regular package which will provide the qmake binary. Likely it makes sense to create a package called mingw-w64-qt6-qmake which would be similar to mingw-w64-cmake so not every package would have to sort out the correct usage individually.
      2. I'll delay building the mingw-w64-qt6-* packages until the corresponding qt6-* are available because I suppose using older tools might not generally work.
      3. Not sure how we'll have to built the deployment tool or generally other Windows specific tools. They will likely not be available within the regular GNU/Linux packages but are still host tools. Maybe one simply builds these in a separate CMake/make invocation using some special parameters.
    3. I'll drop my patches for supporting installing the shared and static version within the same prefix. These patches actually came from the previous maintainer who took them from Fedora. I kept these patches so far because why change a running system. However, now I'd likely need to rewrite the patches completely so it makes more sense to get rid of them. That means I'll use a nested install prefix for the static version similar to the MSYS2 packaging. That means you will no longer be able to use the shared and the static version of Qt within the same CMake project. This was a nice feature but I don't think the benefit is worth the maintenance effort anymore.
    4. Cross compilation for the mingw-w64 target is still not officially supported. So I'll expect to run into problems and I don't expect that Qt 6 packages will be ready immediately after its release (although I'll likely try out beta versions).
    5. Some Qt modules will be moved out to the market place (e.g. Qt Multimedia). This mainly affects the repository URL and decouples these modules from the regular Qt release cycle. I think it makes actually sense because this way we can likely avoid frequent rebuilds of modules which don't change anyways (unless they are using private Qt APIs).

Feel free to comment if you have any ideas or suggestions. Of course we're quite constrained to how upstream plans to do things.

Martchus commented on 2018-05-29 08:29

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:,

Martchus commented on 2018-03-11 20:19

@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


Martchus commented on 2016-07-10 19:47

All my packages are managed at GitHub where you can also contribute directly:

Patches for this package are managed at:
if you like to contribute to patches, read this:

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

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

Latest Comments

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

sgsaenger commented on 2017-08-24 10:13

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

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

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

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

adsun commented on 2017-08-05 23:20

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

@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

Some undefined references in openssl linking.

Any way to fix this?

Martchus commented on 2017-07-06 21:52

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.
- prefixed version which allows using both variants in the same project is still possible:

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

xantares commented on 2017-07-04 21:26

export OPENSSL_LIBS -lssl -lcrypto, those are 1.1?

Martchus commented on 2017-06-08 20:06

Qt 5.9.0 is there :-)
See my previous comment about openssl. Additionally, this is using pcre2 now. The location module now always needs ANGLE at build time (for some plugin), otherwise the build fails. Since problems of patch 0023-Allow-usage-of-static-version-with-CMake.patch still haven't been resolved yet you might want to build without it if you don't need to use the static version with CMake.

Users of my binary repo must execute the following commands after upgrading all Qt modules to be able to use the static version with CMake:
find /usr/{i686,x86_64}-w64-mingw32/lib/cmake -iname 'StaticQt5*Config.cmake' -exec sed -i 's/Qt5::\(.*\)Private/StaticQt5::\1Private/g' {} \;
find /usr/{i686,x86_64}-w64-mingw32/lib -iname 'Qt5*.static.prl' -exec sed -i 's/-lpcre16/-lversion -lpcre2-16/g' {} \;
find /usr/{i686,x86_64}-w64-mingw32/lib/qt/mkspecs/mingw-w64-g++ -iname '*.conf' -exec sed -i 's/-lpcre16/-lversion -lpcre2-16/g' {} \;
(I just don't want to keep my server busy for hours with rebuilding if executing 3 commands is sufficient.)