General discussion about mingw-w64 packages

[Martchus]

General questions and discussions about mingw-w64 packages (previously #94)

[xantares]

did you try to build qt5-webengine ? what was blocking ?

[Martchus]

I haven't tried building it for ages. Back then one had to patch-out a check in the build system to get started but then there were tons of errors. Maybe it works at this point. Maybe the chances of success would be better using clang which can target mingw-w64. One doesn't even have to use a special build of clang, the default clang package is sufficient and one just needs to specify the target. However, I have never tried that to build qt5-webengine because I don't use it anyways for my Windows builds (as shipping a whole browser engine with all its dependencies seems unreasonable in my cases).

Another reason I haven't tried it is that it'll take forever to build on my normal build server and the rest of Qt is already taking very long. And now it is Qt 5 plus Qt 6 and builds targeting Android so I'm afraid building a whole browser engine would exceed what I'm willing to build at the moment. Maybe I'll give it another shot at some point in the future but then I'd likely only cover Qt 6.

[jordan-josephs]

Have you gotten libadwaita to build? I tried messing with the stuff from MSYS2 but couldn't get anything close to working.

[Martchus]

I haven't tried it (because I don't need it). The style would look a little bit out of place on Windows anyways.

[xantares]

my update of mingw-w64-suitesparse 6.0.1 broke the world, but they fixed it in 6.0.2

[Martchus]

I triggered the build: https://martchus.no-ip.biz/buildservice/#build-action-details-section?18

[xantares]

thanks, turns out now mingw-w64-ceres-solver must be rebuilt too because of this

[xantares]

something is off with the curl package; it crashes on a simple example:

$ cd /tmp
$ wget https://raw.githubusercontent.com/xantares/pkgtest/master/test/t_curl.c
$ x86_64-w64-mingw32-gcc t_curl.c -lcurl
$ x86_64-w64-mingw32-wine a.exe 
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
Mingw-w64 runtime failure:
32 bit pseudo relocation at 000000026F53C101 out of range, targeting 00000001DE6928E0, yielding the value FFFFFFFF6F1567DB.

i tried rebuilding mingw-w64-curl (8.0.1) to 7.86.0 and rolling back wine (8.4) to 7.19 without luck: I cannot figure out where this error comes from, any idea ?

I checked some of the curl dependencies are ok: https://github.com/xantares/pkgtest

I rebuilt mingw-w64-curl and deps from sources: its not a problem with your repo

[xantares]

seems netcdf should be rebuilt too

[Martchus]

enqueued the rebuild of netcdf

[Martchus]

Unfortunately the build failed due to linker errors, see https://martchus.no-ip.biz/buildservice/#build-action-details-section?293.

[xantares]

it works for me, difference is I have mingw-w64-cmake 1-40

[Martchus]

I wouldn't have expected that https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-cmake&id=ca13e4896ad9de9d33d9740940bc3925ed5ad512 makes this kind of difference but apparently it does. So the package built now after updating mingw-w64-cmake. (And as shown in https://martchus.no-ip.biz/buildservice/#build-action-details-section?291 I really just was one version of mingw-w64-cmake behind. So the mentioned commit must have made the difference.)

[xantares]

hi Martchus,
I was wondering if mingw-w64-libharu could be added to the repo

[Martchus]

hi - this library doesn't look too big so I'll add it.

[Martchus]

This didn't even take one minute to build :-)

[Martchus]

Looks like this package contains demos for Visual Basic .NET. This was one of my first programming languages so I like it for the sake of nostalgia. However, I'm nevertheless wondering whether it would make sense to remove those probably unneeded files from the package.

[xantares]

I think these files are already removed in the install section

[xantares]

hi @Martchus, the mingw-w64-ceres package has to be rebuilt again after suitesparse update

[Martchus]

@xantares Looks like people are contemplating removing support for certain languages from mingw-w64-gcc on the official bug tracker: https://gitlab.archlinux.org/archlinux/packaging/packages/mingw-w64-gcc/-/issues/1

If you're aware of any AUR packages that still need them I suppose it would be good to object there.

[Martchus]

Be aware of https://gitlab.archlinux.org/archlinux/packaging/packages/mingw-w64-gcc/-/issues/6. Due to this issue I added mingw-w64-gcc to my binary repository which is now version-wise ahread of the official Arch Linux repository. So using packages from my binary repository is proably a bad idea for now if you not also use that updated version of mingw-w64-gcc by placing my binary repoitory before official ones in /etc/pacman.conf. I haven't uploaded the updated PKGBUILD to the AUR because it is probably against the policy.

[Martchus]

And the _Float16 related error goes away with -msse2. However, judging by the output of i686-w64-mingw32-g++ -Q --help=target | grep -i msse of the old compiler version this was also not enabled before. Considering https://en.wikipedia.org/wiki/P6_(microarchitecture) it would also be problematic to add -msse2 as the build wouldn't actually run on all i686 CPUs anymore.

EDIT: This was probably broken by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504#c9 / https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9a19fa8b616f83474c35cc5b34a3865073ced829.

[Martchus]

I'll rebuild GCC 14 with the mentioned patch from MSYS2 which will hopefully fix the problem you encountered. I'll also look into the i686/Qt6/float issue. Maybe Qt just needs to be rebuilt against the new GCC version or I need to revert the mentioned change or find another workaround.

I moved the new GCC version to ownstuff-testing for the time being.

[xantares]

yes, the msys patch fixes the atexit issue

[xantares]

do we really want to bother about i686 nowadays ? I stopped using it years ago

I wonder if we can just build for x86_64 to reduce build time package sizes

[Martchus]

I'd like to keep i686 for core packages but think it is time to disable it for Qt 6 packages (and anything based on them) considering it is no longer supported upstream anyway. (With Qt 5, GCC 14 still works so I'd keep i686 builds on Qt 5 packages enabled. I think there are still users of my software using the 32-bit Qt 5 builds on older Windows versions.)

Note that the i686 target of the compiler is most likely also used by WINE for the lib32 support.

[xantares]

hi, I think there is a problem with the qt 5.15.12 update: the mingw-w64-qt5-base package is missing on the repos: only 5.15.11 is pulled but others mingw-w64-qt5-* package are updated to 5.15.12

[Martchus]

Hi, the mingw-w64-qt5-base package was just not moved from my temporary/experimental repo to the main repo. I guess that's a bug in my build/repo-management tool I'll have to look into. I now redone the move so the package should be there now.

[xantares]

thanks a lot, it works fine now

[xantares]

hi @Martchus, do you mind rebuilding mingw-w64-ceres package again after the glog 0.7 update ?

[Martchus]

I scheduled the build.

[xantares]

thanks, its mingw-w64-ceres-solver though

[xantares]

hello, I'm having link problems with mingw-w64-protobuf, I think it needs a rebuild after the abseil update
I just bumped it

[Martchus]

I started a rebuild.

[zaps166]

Hello! I noticed patch 0032-Fix-crashes-in-rasterization-code-using-setjmp.patch in mingw-w64-qt5-base causes unhandled exception on 32-bit QMPlay2 on my Windows 10 VM. 64-bit QMPlay2 is running fine. When I build without this patch both 32-bit and 64-bit seems to be running correctly. This binary is affected - it launches sometimes, mostly SIGABRT 😭 I use mingw-w64-gcc 13.1.0 compiler.

[zaps166]

I think 32-bit for Qt6 doesn't make sense, because there are no much users of 32-bit Win10 (Qt6 doesn't work on Win7/8).

Interestingly that is something I could not reproduce under WINE

Sometimes app runs under WINE and crashes on Windows (I noticed - especially exceptions). I've checked QMPlay2 with Win11 style - looks good, but haven't used for long (I hope it will not crash 😄).

---

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

That's strange.

Are you sure this app doesn't have any bugs? Random and weird crashes can be caused by memory corruption somewhere else - could you try address sanitizer on this?

[Martchus]

About the Windows 11 style crashes: This happens when not passing a widget when drawing a control. That should be fine according to the documentation (https://doc.qt.io/qt-6/qstyle.html#drawControl) but the Windows 11 style uses the widget unconditionally. This is probably a bug I should report.

[Martchus]

TLDR: Looks like building the latest mingw-w64-binutils and rebuilding apps with the latest mingw-w64-gcc and Qt 6.7.0 makes things work for i686 (still without my patch). So it is definitely not required anymore and it also seems that Qt 6.7.0 is also not completely broken on i686. This all applies to shared and static builds of Qt (as I tested with both).

---

I noticed that mingw-w64-binutils in the official repos is outdated after running into compile errors because the file format of certain objects was not recognized. Turns out I had an even older version of mingw-w64-binutils on my development system (2.32). This old version didn't really didn't like certain objects created with the mingw-w64-bintuils in official repos (2.39):

i686-w64-mingw32-objdump -x /usr/i686-w64-mingw32/lib/libQt6EntryPoint.a
In archive /usr/i686-w64-mingw32/lib/libQt6EntryPoint.a:
i686-w64-mingw32-objdump: qtentrypoint_win.cpp.obj: file format not recognized

I now updated mingw-w64-binutils to 2.42 and with that all problems went away (without rebuilding Qt 6.7.0 against it, just applications). Not sure what exactly the problem was with the old version, though.

(Note that none of the recently built packages in my binary repo were build with mingw-w64-binutils 2.32. This version was really only installed on a development system. Packages in my binary repo will from now on use 2.42.)

By the way, I don't think apps were buggy, especially since they crashed so early in the initialization (where mainly code of Qt itself was running). So maybe the problem was really related to linking libQt6EntryPoint.a.

[zaps166]

About the Windows 11 style crashes

Maybe this is fixed by this commit?

[Martchus]

That is a fix in the same area. For the concrete problem I noticed I have already created https://codereview.qt-project.org/c/qt/qtbase/+/554787 but it hasn't been approved by enough reviewers yet. It was also easily possible to work around it from my side (by simply passing the widget).

[zaps166]

I noticed you added -j$(nproc) to make for some mingw PKGBUILDs, I guess - because MAKEFLAGS are no longer passed into scripts.

I think it's a bug, caused by this. After this commit, the !buildflags option clears MAKEFLAGS, but for this we have separate !makeflags option.

I've sent an email to developer, because creating account process there is weird and I resigned. However if you have account there, you could report this, maybe it'll be fixed 😄

[Martchus]

I have an account and can report a bug later.

This is my best workaround so far (because changing single packages doesn't scale well): https://github.com/Martchus/PKGBUILDs/blob/master/buildenv/default/parallel.sh

[Martchus]

I created https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/25.

[zaps166]

Thanks!

[Martchus]

There's already a MR: https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/163

[xantares]

hi, could lapack & hdf5 mingw packages be rebuilt ?

[Martchus]

done

[xantares]

thank you

[xantares]

hi again, the mingw-coin-or-ipopt and coin-or-ipopt must be rebuillt too because of the coinmumps update.

[Martchus]

done

[FezzedOne]

Just now getting an invalid package signature when I update my MinGW SDL2 package:

error: mingw-w64-sdl2: signature from "Martchus <[email protected]>" is unknown trust
:: File /var/cache/pacman/pkg/mingw-w64-sdl2-2.30.3-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

[Martchus]

I had to upgrade my certificate, see Martchus/syncthingtray#258. So it is probably just that.

I created https://gitlab.archlinux.org/pacman/pacman/-/issues/137 for the not so ideal error message of pacman.

[xantares]

hi, could mingw-w64-gklib & mingw-w64-metis be rebuilt ? there is a potential crash with the new versions

[xantares]

also the *cminpack packages could be updated

[Martchus]

It should all be updated now.