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

Git Clone URL: (read-only)
Package Base: mingw-w64-qt5-base
Description: A cross-platform application and UI framework (mingw-w64)
Upstream URL:
Licenses: custom, GPL3, LGPL3, FDL
Groups: mingw-w64-qt5
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 12
Popularity: 1.918288
First Submitted: 2016-08-30 21:28
Last Updated: 2017-07-06 21:13

Sources (32)

Pinned Comments

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:

There also exist a binary repository:

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.

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

Latest Comments

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.

hein09 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.)

Martchus commented on 2017-06-07 10:32

@xantares As far as I'm concerned there is no such patch. The regular qt5-base still uses the old openssl. I follow this approach for Qt 5.9.0 and it seems to work fine. Hence I already provide mingw-w64-openssl-1.0 which doesn't conflict with mingw-w64-openssl. So the error should be gone when I push 5.9 here. Till then, don't update to openssl to 1.1. Or use the packages for 5.9 which are already available in my PKGBUILDs repo.

All comments