Package Details: mingw-w64-qt5-base 5.15.0-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: 19
Popularity: 0.009830
First Submitted: 2016-08-30 21:28
Last Updated: 2020-06-01 17:57

Sources (32)

Pinned Comments

Martchus commented on 2020-06-09 10:33

Notes regarding Qt 6 packaging

I plan to package Qt 6 as well, 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: 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

@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

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


BTW: Patches to fix this are welcome of course. Since I don't use the plugin myself, I'm currently not motivated to take the effort myself. Updating the mariadb-connector-c packages is also not done yet.

Martchus commented on 2016-07-10 19:47

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

1 2 3 4 5 6 ... Next › Last »

Martchus commented on 2020-06-09 10:33

Notes regarding Qt 6 packaging

I plan to package Qt 6 as well, 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 2019-12-16 14:06

I've already rebased the patches for 5.14.0 but it will likely take a while to fix these issues:

ERROR: Qt requires a compliant STL library.

ERROR: Feature 'gnu-libiconv' was enabled, but the pre-condition '!config.qnx && !config.android && !config.darwin && !features.posix-libiconv && !features.sun-libiconv && libs.gnu_iconv' failed.

ERROR: Feature 'iconv' was enabled, but the pre-condition '!features.icu && features.textcodec && (features.posix-libiconv || features.sun-libiconv || features.gnu-libiconv)' failed.

ERROR: detected a std::atomic implementation that fails for function pointers.
Please apply the patch corresponding to your Standard Library vendor, found in
  qtbase/config.tests/atomicfptr

ERROR: Feature 'system-harfbuzz' was enabled, but the pre-condition 'features.harfbuzz && libs.harfbuzz' failed.

When rebasing I've also noticed that they're tackling the issues with CMake and the static build. That's good because I could finally get rid of my patches for that. However, we still have Merge-shared-and-static-library-trees.patch which came originally from Fedora and the old maintainer. That blocks removing Pull-dependencies-of-static-libraries-in-CMake-modul.patch and Allow-usage-of-static-version-with-CMake.patch in favor of Qt's own recent improvements because only my patches take this special setup into account. So far I've kept the patches. That means Pull-dependencies-of-static-libraries-in-CMake-modul.patch is basically a revert of Qt's own recent improvements in favor to my patch. But when I have more time for testing Qt's implementation I'd like to drop all of the mentioned patches. The static version would be either installed under its own nested prefix or not be co-installable with the shared version. I would also like to make separate packages for the static versions of the additional modules.

xantares commented on 2019-12-03 06:30

martchus, you can use mingw-w64-environment now

Martchus commented on 2019-06-19 21:54

@burning_daylight That would be interesting since the "resurrected" Qt WebKit seems to die after all. However, I'm not sure whether it is possible: https://github.com/Martchus/PKGBUILDs/issues/94#issuecomment-503760600

burning_daylight commented on 2019-06-19 12:43

It seems, chromium can now be built with clang and lld. Qt now uses clang by default on windows. Would it be possible to have Qt WebEngine on mingw?

Martchus commented on 2019-06-14 16:42

Qt 5.13.0 is going to be released on 18.06.2019. I can wait that long and would therefore skip 5.12.4.

Martchus commented on 2019-03-18 22:24

I'd like to give fixing https://github.com/Martchus/PKGBUILDs/issues/86 a few more days before rebuilding everything. If you can't wait for 5.12.2, patches are actually already rebased: https://github.com/Martchus/PKGBUILDs/tree/update/qt5

(Checksums have not been updated yet on this WIP branch.)

Martchus commented on 2019-02-03 23:06

I'm currently in the process of updating to 5.12.1.

Seems they added some changes to the build system which conflict with my effort for making a fully statically linked executable relying on "system libraries" rather than bundles ones. I suppose most of my patches are adapted now. Some workarounds even might be no longer necessary but I also had to add new workarounds. At least it seems not totally messed up so far. I could do a static build of all the tools from the qttools repo (qmake) and of my Syncthing Tray application (CMake).

I noticed that a recent update of the mingw-w64-postgresql package apparently broke the static PostgreSQL plugin. The reason for the breakage seems the same as for the static MySQL plugin. (See pinned comment.)

And I had to fix windeployqt. It seems upstream really doesn't care about cross-compilation for Windows. But at least that patch might be upstream-able.

Martchus commented on 2018-09-21 09:07

Update to 5.11.2 is delayed by https://aur.archlinux.org/packages/mingw-w64-glib2/#comment-663726.

Martchus commented on 2018-09-01 15:02

@alexzk The dependency structure is not different from the regular qt5-base package in that regard. Don't use stupid AUR helper - at least not here. To ease bootstrapping I created mingw-w64-freetype2. There's also my binary repository if you don't want to care about bootstrapping at all.