Package Details: mingw-w64-qt5-base 5.15.4+kde+r135-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
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 21
Popularity: 0.003479
First Submitted: 2016-08-30 21:28 (UTC)
Last Updated: 2022-05-18 09:27 (UTC)

Sources (34)

Pinned Comments

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

Martchus commented on 2022-04-26 10:31 (UTC)

I can update to the latest commit in the KDE-fork this evening. If your commit isn't contained by it I'll add it to my custom patchset. We're already at 32 patches so adding one more is certainly possible :-)

xantares commented on 2022-04-25 15:49 (UTC)

hi,

could this fix be backported as well ?

https://github.com/qt/qtbase/commit/87973325f1b99f2b25a5a0224e623803872ce2ef

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 2020-09-10 12:52 (UTC) (edited on 2020-09-10 12:53 (UTC) by Martchus)

@xantares Thanks for the info. I'll try my luck with Qt 6 when the alpha is out. So far I've only tested the native Linux version and it mostly works well with some minor issues. The next thing is the update to 5.15.1 of course which I'll do tomorrow or on the weekend.

xantares commented on 2020-09-10 09:22 (UTC)

I tried a first build from the dev branch, it's a bit rough to detect dependencies and pkgconfig, but it goes through. (you need to install qt6 first, then pass -DQT_HOST_PATH=/usr)

Martchus commented on 2020-06-09 10:33 (UTC) (edited on 2020-10-08 15:32 (UTC) by Martchus)

Notes regarding Qt 6 packaging

I plan to package Qt 6 as well (see https://aur.archlinux.org/packages/mingw-w64-qt6-base 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 2019-12-16 14:06 (UTC)

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 (UTC)

martchus, you can use mingw-w64-environment now

Martchus commented on 2019-06-19 21:54 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2019-11-09 02:10 (UTC) by Martchus)

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 (UTC)

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 (UTC) (edited on 2018-09-01 15:04 (UTC) by Martchus)

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

alexzk commented on 2018-09-01 13:01 (UTC)

It does circular dependency somewhere in harfbuzz/freetype2 etc. Just tries install stuff in loop.

adsun commented on 2018-08-25 10:37 (UTC)

@Martchus No. I just manually compare the version of mingw-w64 packages with the latest upstream version. Thanks for the patch!

Martchus commented on 2018-08-25 10:04 (UTC)

@adsun Added the patch. Btw, do you have a script to flag mingw-w64 packages (just because you flag my packages so often/fast)?

adsun commented on 2018-08-24 15:31 (UTC)

The build now fails during the qmake build with glibc version 2.28. The native linux qt5 package has a patch that fixes this problem.

Martchus commented on 2018-06-13 12:16 (UTC)

@luntik2012 "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." Did you follow this instruction?

luntik2012 commented on 2018-06-13 12:13 (UTC)

i686-w64-mingw32-g++ -g -shared -Wl,-subsystem,windows -Wl,--out-implib,/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib/libQt5Gui.dll.a -o ../../lib/Qt5Gui.dll object_script.Qt5Gui.Release -lcomdlg32 -loleaut32 -limm32 -lwinmm -lws2_32 -lole32 -luuid -ladvapi32 -ljpeg -lpng -L/usr/i686-w64-mingw32/lib -lharfbuzz -lfreetype -lglu32 -lopengl32 -lgdi32 -luser32 -L/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libQt5Core.dll.a -lpng -lharfbuzz -lz ./.obj/release/qtextengine.o:/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/qtbase-everywhere-src-5.11.0/include/QtCore/../../src/corelib/tools/qstringview.h:270: undefined reference to `_imp___ZN9QtPrivate13isRightToLeftE11QStringView' collect2: error: ld returned 1 exit status make[3]: [Makefile.Release:1183: ../../lib/Qt5Gui.dll] Error 1 make[3]: Leaving directory '/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/gui' make[2]: [Makefile:36: release] Error 2 make[2]: Leaving directory '/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/gui' make[1]: [Makefile:523: sub-gui-make_first] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-base/src/build-i686-w64-mingw32/src' make: [Makefile:45: sub-src-make_first] Error 2 ==> ERROR: A failure occurred in build().

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-05-29 08:25 (UTC)

@tsdgeos It tries to link the new Qt Gui against the old, installed version of Qt Core. Likely _imp___ZN9QtPrivate13isRightToLeftE11QStringView is a recently added symbol. Please remove the currently installed version and try again. In fact this is a known limitation which was already present before I started to maintain this package. I should mention it in the pinned comment.

tsdgeos commented on 2018-05-29 07:45 (UTC)

5.11.0-1 fails to build for me, anyone else having the problem or any idea what may be the fix?

https://paste.kde.org/pw9diuw2v

Martchus commented on 2018-05-27 12:48 (UTC)

I'm currently updating to 5.11.0. So far I have already found three new problems and the compilation is only half way through :-/

  • The definition of _xgetbv in /usr/i686-w64-mingw32/include/psdk_inc/intrin-impl.h conflicts with the definition of the same function in /usr/lib/gcc/i686-w64-mingw32/8.1.0/include/x86intrin.h. As a workaround, I added -D__INTRINSIC_DEFINED__xgetbv to the compiler flags.
  • I had to disable the hardware randomizer for 32-bit due to an internal compiler error (https://github.com/Martchus/PKGBUILDs/blob/update/mingw-w64-qt5/qt5-base/mingw-w64/0033-Disable-hardware-randomizer-for-32-bit.patch).
  • The winextras module now links directly against dwmapi. Apparently some of the required symbols are absent in the x86_64 version of libdwmapi.a provided by mingw-w64-crt 5.0.3. So I'll reverted the commit in qtwinextras for now.

So that's basically the reason why updates take some time here. Note that all of these issues are caused by mingw-w64/GCC for Windows and not by Qt itself.

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)

theone74 commented on 2018-03-11 19:44 (UTC) (edited on 2018-03-11 19:45 (UTC) by theone74)

@Martchus Hi! when i build this example https://github.com/oggio88/Qt-CMake-HelloWorld it works fine, but if i add QT+=sql i get link error

/usr/x86_64-w64-mingw32/lib/libpthread.a(libwinpthread_la-cond.o): In function `pthread_cond_init':
/build/mingw-w64-winpthreads/src/mingw-w64-v5.0.3/mingw-w64-libraries/winpthreads/src/cond.c:196: multiple definition of `pthread_cond_init'
/usr/x86_64-w64-mingw32/lib/libmariadbclient.a(my_pthread.c.obj):(.text+0x0): first defined here
/usr/x86_64-w64-mingw32/lib/libpthread.a(libwinpthread_la-cond.o): In function `pthread_cond_destroy':
/build/mingw-w64-winpthreads/src/mingw-w64-v5.0.3/mingw-w64-libraries/winpthreads/src/cond.c:248: multiple definition of `pthread_cond_destroy'
/usr/x86_64-w64-mingw32/lib/libmariadbclient.a(my_pthread.c.obj):(.text+0x90): first defined here
/usr/x86_64-w64-mingw32/lib/libpthread.a(libwinpthread_la-cond.o): In function `pthread_cond_wait':
/build/mingw-w64-winpthreads/src/mingw-w64-v5.0.3/mingw-w64-libraries/winpthreads/src/cond.c:415: multiple definition of `pthread_cond_wait'
/usr/x86_64-w64-mingw32/lib/libmariadbclient.a(my_pthread.c.obj):(.text+0x80): first defined here
/usr/x86_64-w64-mingw32/lib/libpthread.a(libwinpthread_la-cond.o): In function `pthread_cond_timedwait':
/build/mingw-w64-winpthreads/src/mingw-w64-v5.0.3/mingw-w64-libraries/winpthreads/src/cond.c:514: multiple definition of `pthread_cond_timedwait'
/usr/x86_64-w64-mingw32/lib/libmariadbclient.a(my_pthread.c.obj):(.text+0x70): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile.Release:69: release/config.exe] Error 1
make[1]: Leaving directory '/home/devel/Qt-CMake-HelloWorld'
make: *** [Makefile:36: release] Error 2

What am I doing wrong?

Martchus commented on 2018-01-04 21:16 (UTC) (edited on 2018-01-04 21:18 (UTC) by Martchus)

While building this package? Mh... strange since I was able to build successfully. To be honest, I've only built 5.10.0-1 and not 5.10.0-2 so far, but looking at the diff I doubt that this makes a difference.

To help you, I need a little bit more context (the failing command at least). Whether you're actually talking about mingw-w64-qt5-base (and not eg. mingw-w64-qt5-base-static), your AUR helper and whether you're building in a clean chroot would also be good to know.

Hudd commented on 2018-01-04 21:05 (UTC)

I ran into a problem with case sensitivity while building this package.

ld: cannot find -lVersion

Martchus commented on 2017-12-15 21:56 (UTC) (edited on 2017-12-15 21:59 (UTC) by Martchus)

I found the bug causing CMake to add -L/lib on the linker line and fixed it. The bug only affected projects which link against static Qt plugins.

When you have already built the latest version or you're using my binary repo, just execute the following commands to apply the fix:

find /usr/x86_64-w64-mingw32/lib/cmake -iname 'StaticQt5*Config.cmake' -exec sed -i 's/\"\${_qt5Svg_install_prefix}\/lib\" static\_depends/\"\/usr\/x86_64-w64-mingw32\/lib\" static\_depends/g' {} \;
find /usr/i686-w64-mingw32/lib/cmake -iname 'StaticQt5*Config.cmake' -exec sed -i 's/\"\${_qt5Svg_install_prefix}\/lib\" static\_depends/\"\/usr\/i686-w64-mingw32\/lib\" static\_depends/g' {} \;

Otherwise it would be required to rebuild each and every package mingw-w64-qt5-* package.

Martchus commented on 2017-12-15 19:39 (UTC) (edited on 2017-12-15 19:40 (UTC) by Martchus)

@specialworld83 It's not a bug, it's a feature. That is actually true, since the widget styles have just been refactored to separate plugins. So you just need to deploy the corresponding plugin which is located under eg. /usr/x86_64-w64-mingw32/lib/qt/plugins/styles/qwindowsvistastyle.dll. If you're using the static variant, you need to link against the static plugin like you need to link against the platform integration plugin.

specialworld83 commented on 2017-12-15 12:57 (UTC)

Good moorning, the style windowsvista not working on windows 7/8/10.

Thanks

Martchus commented on 2017-12-10 19:49 (UTC) (edited on 2017-12-15 19:56 (UTC) by Martchus)

I'll push 5.10.0 when the regular package is moved from testing to extra:

  • The following new packages are available
    • mingw-w64-qt5-speech: without flite and speech-dispatcher backends because mingw-w64 packages for those dependencies are not available
    • mingw-w64-qt5-remoteobjects
    • mingw-w64-qt5-networkauth
  • Using MariaDB with the static version still does not work, see comment: https://aur.archlinux.org/packages/mingw-w64-mariadb-connector-c
  • Rough edges about the static version are still not gone.
    • However, I'm able to build qmake projects (eg. all Qt modules) by just adding 'CONFIG+=no_smart_library_merge CONFIG+=static' to qmake arguments and it includes platform plugins.
    • When using CMake, I'm currently getting a -L/lib on the linker line leading to linker segfault. This issue was already present some time ago, have to further investigate where this cross-compilation-disturbing search path comes from.
  • I disabled building the mapbox-gl plugin in mingw-w64-qt5-location as it takes a significat time to compile and is likely not used by a lot of people. To enable it, see the comment in the corresponding PKGBUILD.
  • Updating mingw-w64-qt5-webkit to ng version is still TODO.

(Updated PKGBUILDs are already pushed to https://github.com/Martchus/PKGBUILDs.)

Martchus commented on 2017-11-26 20:02 (UTC) (edited on 2017-11-26 20:02 (UTC) by Martchus)

Qt 5.9.3 is out. However, I'm a bit busy next week so maybe I just skip that release and update to 5.10 right away. 5.10 is likely to be released in the beginning of December which is also quite close.

z3ntu commented on 2017-10-17 20:31 (UTC)

@Martchus: Thanks, I uninstalled and built and installed again. I tried to make it work with extra-x86_64-build but there were too many dependencies to manually add... I'll remember for next time. Thanks for maintaining the package!

Martchus commented on 2017-10-16 21:13 (UTC)

Seems like it tries to link Qt Widgets against the currently installed version of Qt Core and Gui. This is not possible because private ABI might (and actually has) changed. Hence those linker errors only relate to private symbols of the Qt library. Not sure what makes Qt linking against the installed/previous version now. I'd simply work around this by uninstalling the previous version or build in a clean chroot. I always do the latter and hence didn't encounter this issue when building myself.

z3ntu commented on 2017-10-16 20:59 (UTC)

I get link errors with 5.9.2: i686-w64-mingw32-g++ -g -shared -Wl,-subsystem,windows -Wl,--out-implib,/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib/libQt5Widgets.dll.a -o ../../lib/Qt5Widgets.dll object_script.Qt5Widgets.Release -lcomdlg32 -loleaut32 -limm32 -luuid -ladvapi32 -ljpeg -lpng -L/usr/i686-w64-mingw32/lib -lfreetype -lbz2 -lharfbuzz -lglib-2.0 -lws2_32 -lole32 -lwinmm -lshlwapi -lpcre -lintl -liconv -lgraphite2 -lglu32 -lopengl32 -lgdi32 -luser32 -L/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libQt5Gui.dll.a /usr/i686-w64-mingw32/lib/libQt5Core.dll.a -lshell32 -luxtheme -ldwmapi ./.obj/release/qdirmodel.o: In function `ZNK16QDirModelPrivate4nameERK11QModelIndex': /mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qdirmodel.cpp:1285: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString' ./.obj/release/qdirmodel.o: In function `ZNK9QDirModel8fileNameERK11QModelIndex': /mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qdirmodel.cpp:1108: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString' ./.obj/release/qfileiconprovider.o: In function `ZNK17QFileIconProvider4typeERK9QFileInfo': /mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qfileiconprovider.cpp:303: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString' ./.obj/release/qfileiconprovider.o: In function `ZNK17QFileIconProvider4iconERK9QFileInfo': /mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qfileiconprovider.cpp:252: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString' collect2: error: ld returned 1 exit status make[3]: *** [Makefile.Release:867: ../../lib/Qt5Widgets.dll] Error 1 make[3]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/widgets' make[2]: *** [Makefile:36: release] Error 2 make[2]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/widgets' make[1]: *** [Makefile:627: sub-widgets-make_first] Error 2 make[1]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src' make: *** [Makefile:45: sub-src-make_first] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Martchus commented on 2017-10-16 17:57 (UTC) (edited on 2017-10-16 18:01 (UTC) by Martchus)

Updated to 5.9.2. I also fixed qmake so it now links against static plugins by default when using the static variant. This didn't work (anymore) because of our way to merge shared and static builds. However, this revealed further bugs: * qmake is messing dependency cycle of static freetype and harfbuzz. This can be worked around by adding `CONFIG+=no_smart_library_merge` to qmake arguments. * qmake does not include dependencies of static Qt modules when only linking against a plugin which pulls that Qt module but not using the module itself explicitly. Just link against the module explicitly by adding `QT+=the_module` to qmake arguments. * The Qt Network module can not be used with the static MySQL plugin because the plugin's its dependency mariadb-connector-c uses OpenSSL 1.1 while Qt is still using OpenSSL 1.0. Both versions can not be combined. Qt 5.10 will fix this by supporting OpenSSL 1.1. BTW: If you need Qt location but not the included mapbox-gl plugin, I suggest disabling this feature as it requires a lot of time to compile. The binaries provided at my repository will not include the plugin anymore (for now).

Martchus commented on 2017-09-04 16:41 (UTC)

> As i said, i have missing references in libQt5Widgets.a(qwindows{vista|xp}style.o) and libQt5Gui.a(qopenglpaintengine.o). I need the cmake/qmake call, the compiler/linker line which fails and the error output. Otherwise I can just do some guessing. > I noticed that neither qopenglpaintengine.a nor qwindows*.a files exist in mingw-w64-qt5-base-static, but i guess i need them at compile-time? If you believe some files are missing in your mingw-w64-qt5-base-static packages, just download the one from my repository (linked in the pinned comment) and compare the files. Note that the mentioned libraries are 'static plugins', so they are in an extra subdirectory (this is not Windows specific at all). Eg. libqwindows.a should be located under /usr/x86_64-w64-mingw32/lib/qt/plugins/platforms/libqwindows.a. You need those files at compile time, if you want to use them (you very likely want the platform integration plugin). Note that this package also contains symlinks for the static plugins eg. /usr/x86_64-w64-mingw32/lib/libqwindows.a, but this shouldn't actually be required (just some precaution to prevent errors in case of plugin path is missing). > As the static libQt5*.a files only contain the references? The libQt5*.a libraries should not contain any references to the plugins. The plugins are optional additions loaded via dlopen (or similar under Windows) or in case of the static variant 'optionally built-in'. In the latter case the actual application must contain the references (eg. via http://doc.qt.io/qt-5/qtplugin.html#Q_IMPORT_PLUGIN).

sgsaenger commented on 2017-09-04 09:39 (UTC)

Thanks for your help! I applied the patch you linked. Unfortunately, i can't get it to work, i still have the linking problems with the windows-stuff... I'm really not well-versed, so please bear with me :) As i said, i have missing references in libQt5Widgets.a(qwindows{vista|xp}style.o) and libQt5Gui.a(qopenglpaintengine.o). I noticed that neither qopenglpaintengine.a nor qwindows*.a files exist in mingw-w64-qt5-base-static, but i guess i need them at compile-time? As the static libQt5*.a files only contain the references? But why does dynamic linking then work, when mingw-w64-qt5-base too does not contain these files? Have they maybe been created while building the mingw-packages and linked into the .dll's, but not copied over or built when composing the static package? I guess i'll wait for the next update, this seems to go far beyond my understanding...

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.

xantares commented on 2017-07-04 21:26 (UTC)

hi, export OPENSSL_LIBS -lssl -lcrypto, those are 1.1? xan.

Martchus commented on 2017-06-08 20:06 (UTC) (edited on 2017-06-08 20:08 (UTC) by Martchus)

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 (UTC)

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

xantares commented on 2017-06-07 06:35 (UTC)

hi, it doesnt build because of openssl>= 1.1, is there a similar patch for what's available for qt4 ? xan.

Martchus commented on 2017-05-01 22:18 (UTC)

Note that this is likely not compatible with the latest version of mingw-w64-openssl so I wouldn't recommend updating it so far. Maybe a package mingw-w64-openssl-1.0 like the regular openssl-1.0 is required.

Martchus commented on 2017-02-07 00:39 (UTC)

Current version is on 'update/qt5' branch of my PKGBUILDs repository: https://github.com/Martchus/PKGBUILDs/tree/update/qt5 I haven't pushed it yet because there are still some outstanding problems with the static variant. One is that dependencies are not correctly written in prl files. However, those files are used by the CMake modules which hence not work correctly (specifically the dependency cycle between freetype2 and harfbuzz is messed). Not sure how to fix this. Also building qt5-tools failed last time I tried to build it due to missing dependencies required by Qt DBus. This should be fixed now, but I'll have to verify first.

Martchus commented on 2017-01-25 18:48 (UTC)

Updating this to 5.8.0 will take some time. Patches are rebased, however the new config system doesn't allow to configure Qt in the same way as it was possible in previous versions (can not use iconv and pkg-config for instance).

dviktor commented on 2017-01-01 22:07 (UTC)

I have cleared ~/.cache/pacaur completely and after that all compiled fine!

Martchus commented on 2016-12-31 14:01 (UTC)

@dviktor Seems like something is completely messed in your build. Have you tried to discard it completely and rebuild from the scratch (preferably in clean chroot, at you have to uninstall previous version of the package)? It would be also helpful to have English error messages. I assume the header file can not be found? Actually it is quite strange that those header files are included when building the Windows version.

dviktor commented on 2016-12-31 10:08 (UTC)

Some errors: ../../../../qtbase-opensource-src-5.7.1/config.tests/unix/getifaddrs/getifaddrs.cpp:48:24: фатальная ошибка: sys/socket.h: Нет такого файла или каталога #include <sys/socket.h> ../../../../qtbase-opensource-src-5.7.1/config.tests/unix/ppoll/ppoll.cpp:41:18: фатальная ошибка: poll.h: Нет такого файла или каталога #include <poll.h> ../../../../qtbase-opensource-src-5.7.1/config.tests/unix/openvg/openvg.cpp:46:23: фатальная ошибка: VG/openvg.h: Нет такого файла или каталога #include <VG/openvg.h> ../../../../qtbase-opensource-src-5.7.1/config.tests/unix/alsa/alsatest.cpp:40:28: фатальная ошибка: alsa/asoundlib.h: Нет такого файла или каталога #include <alsa/asoundlib.h> i686-w64-mingw32-g++ -g -shared -Wl,-subsystem,windows -Wl,--out-implib,/home/viktor/.cache/pacaur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib/libQt5Gui.dll.a -o ../../lib/Qt5Gui.dll object_script.Qt5Gui.Release -lcomdlg32 -loleaut32 -limm32 -luuid -ladvapi32 -ljpeg -lpng -L/usr/i686-w64-mingw32/lib -lharfbuzz -lglib-2.0 -lws2_32 -lole32 -lwinmm -lshlwapi -lpcre -lintl -liconv -lgraphite2 -lfreetype -lbz2 -lglu32 -lopengl32 -lgdi32 -luser32 -L/home/viktor/.cache/pacaur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libQt5Core.dll.a -lharfbuzz -lz -lpng16 ./.obj/release/qtextdocument_p.o: In function `ZN16QFragmentMapDataI17QTextFragmentDataE14createFragmentEv': /home/viktor/.cache/pacaur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.7.1/include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/text/qfragmentmap_p.h:258: undefined reference to `_imp___Z26qCalculateGrowingBlockSizejjj' ./.obj/release/qtextdocument_p.o: In function `ZN16QFragmentMapDataI14QTextBlockDataE14createFragmentEv': /home/viktor/.cache/pacaur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.7.1/include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/text/qfragmentmap_p.h:258: undefined reference to `_imp___Z26qCalculateGrowingBlockSizejjj' collect2: ошибка: выполнение ld завершилось с кодом возврата 1

dviktor commented on 2016-12-31 08:55 (UTC)

Still can not update to the 5.7.1... A lot of compile errors (including missing headers pulseaudio.h and linker issues), I'll try to post some of them later...

Martchus commented on 2016-12-22 10:30 (UTC)

All patches have been rebased already. Just linker error in location module (and maybe errors further in the build process) are currently blocking update to 5.7.1.

luspi commented on 2016-12-16 03:49 (UTC)

Thanks for your packages, but the md5sums for the patches are wrong here...

Salamandar commented on 2016-09-12 16:55 (UTC)

mingw-w64-postgresql-libs does not exist in the AUR, please change the dependency to mingw-w64-postgresql ;)

Martchus commented on 2016-08-31 20:11 (UTC)

I updated the mingw-w64-qt5-base packages to fix issues with the static version and to make the static version usable with CMake. (See the comments in the PKGBUILD.) Also, the variant using native OpenGL is now the default variant. I made this decision because building ANGLE with mingw-w64 is problematic. Of course the ANGLE version is still available (mingw-w64-qt5-base-angle), it is just not the default package anymore. The static version now also provides OpenGL support (via native OpenGL) to be able to build static versions of further Qt modules and statically linked applications requiring OpenGL. I will also update the other Qt packages to provide static libraries. Whether the static libraries are built can be controlled by setting environment variables so it will be possible to avoid the static build if not required.

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.

Edric commented on 2015-11-16 17:18 (UTC)

Patching configure file like so fixes QSemaphore problem @@ -4456,7 +4456,7 @@ if compileTest unix/ipc_posix "ipc_posix" ; then QCONFIG_FLAGS="$QCONFIG_FLAGS QT_POSIX_IPC" else - if [ "$XPLATFORM_ANDROID" = "no" ] ; then + if [ "$XPLATFORM_ANDROID" = "no"] && ["$XPLATFORM_MINGW" = "no" ] ; then QCONFIG_FLAGS="$QCONFIG_FLAGS QT_NO_SYSTEMSEMAPHORE QT_NO_SHAREDMEMORY" fi fi

ant32 commented on 2015-09-17 18:09 (UTC)

http://sourceforge.net/projects/mingw-w64-archlinux/files/x86_64/mingw-w64-qt5-base-opengl-5.5.0-1-x86_64.pkg.tar.xz/download

Edric commented on 2015-09-17 16:09 (UTC)

You're right. Did a full rebuild on a clean docker.

ant32 commented on 2015-09-16 23:20 (UTC)

I'm thinking it somehow tries linking the the native or installed mingw-qt5 build. You probably need to uninstall either or both before building or build in a clean chroot. I currently don't want to take the time to find the bug.

Edric commented on 2015-09-16 15:19 (UTC)

Seems i have undefined symbols : cd widgets/ && ( test -e Makefile || /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/qmake /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/qtbase-opensource-src-5.5.0/src/widgets/widgets.pro -o Makefile ) && make -f Makefile WARNING: Failure to find: .obj/release/Qt5Widgets_resource_res.o WARNING: Failure to find: .obj/debug/Qt5Widgetsd_resource_res.o /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: symbol lookup error: /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: undefined symbol: _ZN7QString14toLower_helperERS_ /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: symbol lookup error: /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: undefined symbol: _ZN7QString14toLower_helperERS_ make[2]: Entering directory '/home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/src/widgets' make -f Makefile.Release make[3]: Entering directory '/home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/src/widgets' /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/qtbase-opensource-src-5.5.0/src/widgets/dialogs/qfiledialog.ui -o .uic/ui_qfiledialog.h /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: symbol lookup error: /home/edric/Downloads/mingw-w64-qt5-base-opengl/src/build-x86_64-w64-mingw32/bin/uic: undefined symbol: _ZN7QString14toLower_helperERS_ Thanks for all the work

ant32 commented on 2015-08-10 16:06 (UTC)

Yes. I'm hoping to do it this week. I spent some hours updating patches but see now that Fedora updated so copying there patches shouldn't be much work.

Edric commented on 2015-08-10 14:15 (UTC)

Hi, any plan to bump this to 5.5 ? Thanks,

ant32 commented on 2015-03-11 04:54 (UTC)

I just tested and my data entry / reporting app works fine with angle on Windows XP

codestation commented on 2015-02-15 19:26 (UTC)

Thanks for the update. Without the angleproject dependency Qt apps can run on XP again (still have some users using it).

ant32 commented on 2015-02-09 20:32 (UTC)

Finally fixed opengl. Yeh!! :)

ant32 commented on 2013-12-31 02:03 (UTC)

added package since for more people angleprject doesn't work. For binaries, repo and changes please visit. http://mingw-w64-archlinux.sourceforge.net/