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 <martchus@gmx.net>" 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.

[Martchus]

I've been adding a few mingw-w64-clang-aarch64-* packages. They allow to target aarch64-w64-mingw32 using Clang from the regular/official clang package. So my packaging only includes mingw-w64 and the compiler runtime but no additional compiler. So far I only compiled a simple hello world program in C. The next step would be the usual wrapper/helper packages and libc++ to be able to compile C++.

Manually adding mingw-w64-clang-aarch64- counterparts for the many mingw-w64- we already have is not feasible. I'm going to write a conversion script that will be invoked by my build scripts on-the-fly. This should be pretty easy as generally only dependency names and _targets need to be replaced.

Note that this approach could also be used to target ucrt for x86_64 but I don't really see a benefit in that now.

[xantares]

hi, there seems to be an issue with the new mingw packages in version 12.0:

The function std::seekg gives undefined refs:

main.cxx:
#include <fstream>
#include <iostream>

int main() {
  std::ifstream in("/tmp/a", std::ios::in);
  in.seekg(0, std::ifstream::beg);// ok
  in.seekg(0);// undefined reference
  in.close();
  return 0;
}

$ x86_64-w64-mingw32-g++ main.cxx
/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/cceje4z0.o:main.cxx:(.text+0x7c): undefined reference to `std::istream::seekg(std::fpos<_Mbstatet>)'
collect2: error: ld returned 1 exit status

this is ok with prior version 11.0.0 (or native linux)

[Martchus]

I'll definitely look into it because applications that are important to me are using it extensively :-)

[Martchus]

I'm not on my Arch system but I started a rebuilt of my tagparser library on the server in a clean chroot environment: https://martchus.dyn.f3l.de/buildservice/#build-action-details-section?1113

Let's see whether it works. Note that this library uses both overloads (and the iostream library in general) a lot, see https://github.com/search?q=repo%3AMartchus%2Ftagparser+seekg&type=code.

(I am using static_cast<std::streamoff>(…) in that code so I can treat warnings about implicit conversions as errors. Maybe that makes it use a different overload as in your example.)

[Martchus]

Looks like there's actually more broken:

CMake Error at /usr/i686-w64-mingw32/share/c++utilities-shared/cmake/modules/3rdParty.cmake:381 (message):
  Unable to compile a simple std::filesystem example.  A compiler supporting
  C++17 is required to build this project.
Call Stack (most recent call first):
  CMakeLists.txt:193 (use_standard_filesystem)

557         Run Build Command(s): /usr/bin/ninja -v cmTC_1be27
558         [1/2] /usr/lib/ccache/bin/i686-w64-mingw32-g++ -DSTD_FILESYSTEM_TEST_0  -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fcf-protection  -std=gnu++17 -o CMakeFiles/cmTC_1be27.dir/src.cxx.obj -c /build/mingw-w64-tagparse    r/src/tagparser-12.2.0/build-i686-w64-mingw32-shared/CMakeFiles/CMakeScratch/TryCompile-WnrKfR/src.cxx
559         [2/2] : && /usr/lib/ccache/bin/i686-w64-mingw32-g++ -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fcf-protection -Wl,-O1,--sort-common,--as-needed -fstack-protector CMakeFiles/cmTC_1be27.dir/src.cxx.obj -o cmTC_1be27    .exe -Wl,--out-implib,libcmTC_1be27.dll.a -Wl,--major-image-version,0,--minor-image-version,0  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && :
560         FAILED: cmTC_1be27.exe 
561         : && /usr/lib/ccache/bin/i686-w64-mingw32-g++ -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fcf-protection -Wl,-O1,--sort-common,--as-needed -fstack-protector CMakeFiles/cmTC_1be27.dir/src.cxx.obj -o cmTC_1be27.exe -    Wl,--out-implib,libcmTC_1be27.dll.a -Wl,--major-image-version,0,--minor-image-version,0  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && :
562         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.text.startup+0xb9): undefined reference to `std::codecvt<wchar_t, char, _Mbstatet>::codecvt(unsigned int)'
563         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.text.startup+0x1a7): undefined reference to `std::__codecvt_utf8_utf16_base<wchar_t>::do_out(_Mbstatet&, wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const'
564         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.rdata$_ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE[__ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE]+0x10): undefined reference to `std::__codecvt_utf8_utf16    _base<wchar_t>::do_out(_Mbstatet&, wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const'
565         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.rdata$_ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE[__ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE]+0x14): undefined reference to `std::__codecvt_utf8_utf16    _base<wchar_t>::do_unshift(_Mbstatet&, char*, char*, char*&) const'
566         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.rdata$_ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE[__ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE]+0x18): undefined reference to `std::__codecvt_utf8_utf16    _base<wchar_t>::do_in(_Mbstatet&, char const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const'
567         /usr/lib/gcc/i686-w64-mingw32/14.1.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/cmTC_1be27.dir/src.cxx.obj:src.cxx:(.rdata$_ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE[__ZTVSt18codecvt_utf8_utf16IwLm1114111ELSt12codecvt_mode0EE]+0x24): undefined reference to `std::__codecvt_utf8_utf16    _base<wchar_t>::do_length(_Mbstatet&, char const*, char const*, unsigned int) const'
568         collect2: error: ld returned 1 exit status
569         ninja: build stopped: subcommand failed.

Maybe every symbol using _Mbstatet is broken. Maybe recompiling GCC against the new mingw-w64 version helps.

[Martchus]

I could reproduce the problem with your simple program as well. It works again after upgrading/rebuilding GCC. Apparently it is necessary to rebuild GCC after updating mingw-w64. Unfortunately it also seems that some other libraries are affected as well, e.g. the build of the mentioned library failed now on some boost symbols also using std::codecvt. I hope not too many libraries are affected.

[xantares]

yes, it works now, thanks

[xantares]

I'm seeing the mingw-w64-boost 1.85 update eventhough my package is still 1.83, did you need it ? I try to stick to the same versions as the native packages but there can be exceptions ofc

[Martchus]

I had to rebuild it anyway so I decided I might as well update it. When it comes to boost I wouldn't generally wait for the official package as it is sometimes out of date for a very long time.

[Martchus]

Also see my AUR comment on the package.

[xantares]

hello,

I'm seeing a problem with mingw-w64-protobuf update, I'm only getting the 27.3 version
I saw the 28.1 version is in /x86_64 instead of /any
https://martchus.dyn.f3l.de/repo/arch/ownstuff/os/x86_64/
is this right ? many other 'any' packages are there too

[xantares]

hello,
I'm having issues with mingw-w64-protobuf being updated to 30.2 although the native package is still at 30.1.
It's causing compilation failures because protobuf is strict about the version allowed for cross-compilation.
Similarly mingw-w64-boost is giving me compilations problems with 1.88 for which I cannot push updates since you seem to be maintaining your own fork of aur packages.
Would it be possible to stick to the native packages versions ? Or do I have to manually pin everything ? Or maybe have a separate repo for newer packages ?
Regards

[Martchus]

I should indeed go back to protobuf 30.1 for now. So I've just done that. (Version 30.2 of the regular package is already in staging so I'll add 30.2 back as soon as it is in extra.)

For boost I prefer having the latest version - especially because it can take very long until the regular boost package is updated but I want to follow upstream more closely. It also doesn't depend on the regular boost package so there's no need to keep the packages in sync. What's the problem with the latest version of boost?

In the future I could keep packages longer in my testing repo if that's helpful for you.

Note that I mainly keep my own versions for two reasons: Support building with Clang (for aarch64) and better support for static libraries (installing static libraries under a static sub-prefix if needed).

[xantares]

Thanks, but now protobuf has been updated to 30.2! :]
For boost it turns out it seems to be just a deprecated api.
It's true that in the past they have been slow to follow boost updates but it seems better nowadays, as 1.88 is already in testing.

[Martchus]

30.2 is just in testing so I keep it in my testing until it hits extra. That's the workflow I normally follow. Of course there is always an unavailable delay.

1.88 is actually only in staging but this means I can rebuild stuff in my repo putting it in my own staging first.

[Martchus]

Ok, now packages have been moved to extra/testing respectively so I moved packages in my testing as well. This also means an updated binutils and GCC.

By the way, if there's interest in grpc I can upload that and the related Qt 6 module to the AUR. It unfortunately needs the patched binutils from my PKGBUILDs repo so perhaps that's not super useful if one needs to build from my Git repo or use the binary repo anyway.

[xantares]

hello again,
it seems mingw-w64-boost needs to be rebuilt for gcc 15 since get undefined reference to std::ios_base::Init::Init()
in libboost_program_options.a, and a rebuild gets rid of the issue

[Martchus]

done

[xantares]

hello, in the same fashion all the coin-or packages should be rebuilt:

• mingw-w64-coin-or-asl
• mingw-w64-coin-or-cgl
• mingw-w64-coin-or-clp
• mingw-w64-coin-or-cbc
• mingw-w64-coin-or-coinmumps
• mingw-w64-coin-or-coinutils
• mingw-w64-coin-or-ipopt
• mingw-w64-coin-or-osi

and also:

• mingw-w64-hdf5
• mingw-w64-ceres-solver
• mingw-w64-nlopt

[xantares]

I think it could affect way more c++ packages that have not been rebuilt since the gcc 15 update.

[Martchus]

I don't think mingw-w64-hdf5 built when I tried to build it last time but I can try again.

[Martchus]

I rebuilt everything on your list for now - except hdf5 which still fails:

[ 37%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_datatype.c.obj
In file included from /build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tinit_float.c:27:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tinit_float.c: In function ‘H5T__init_native_float_types’:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:21: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 10 has type ‘DWORD’ {aka ‘long unsigned int’} [-Wformat=]
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  176 |                     myerrno, strerror(myerrno), win_error);                                                  \
      |                                                 ~~~~~~~~~
      |                                                 |
      |                                                 DWORD {aka long unsigned int}
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:48:72: note: in definition of macro ‘HERROR’
   48 |         H5E_printf_stack(__FILE__, __func__, __LINE__, maj_id, min_id, __VA_ARGS__);                         \
      |                                                                        ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:86:9: note: in expansion of macro ‘HCOMMON_ERROR’
   86 |         HCOMMON_ERROR(maj, min, __VA_ARGS__);                                                                \
      |         ^~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:174:9: note: in expansion of macro ‘HGOTO_ERROR’
  174 |         HGOTO_ERROR(majorcode, minorcode, retcode,                                                           \
      |         ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tinit_float.c:477:9: note: in expansion of macro ‘HSYS_GOTO_ERROR’
  477 |         HSYS_GOTO_ERROR(H5E_DATATYPE, H5E_CANTSET, FAIL, "can't save floating-point environment");
      |         ^~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:84: note: format string is defined here
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                                                                                   ~^
      |                                                                                    |
      |                                                                                    unsigned int
      |                                                                                   %lu
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:21: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 10 has type ‘DWORD’ {aka ‘long unsigned int’} [-Wformat=]
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  176 |                     myerrno, strerror(myerrno), win_error);                                                  \
      |                                                 ~~~~~~~~~
      |                                                 |
      |                                                 DWORD {aka long unsigned int}
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:48:72: note: in definition of macro ‘HERROR’
   48 |         H5E_printf_stack(__FILE__, __func__, __LINE__, maj_id, min_id, __VA_ARGS__);                         \
      |                                                                        ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:86:9: note: in expansion of macro ‘HCOMMON_ERROR’
   86 |         HCOMMON_ERROR(maj, min, __VA_ARGS__);                                                                \
      |         ^~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:174:9: note: in expansion of macro ‘HGOTO_ERROR’
  174 |         HGOTO_ERROR(majorcode, minorcode, retcode,                                                           \
      |         ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tinit_float.c:613:9: note: in expansion of macro ‘HSYS_GOTO_ERROR’
  613 |         HSYS_GOTO_ERROR(H5E_DATATYPE, H5E_CANTSET, FAIL, "can't clear floating-point exceptions");
      |         ^~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:84: note: format string is defined here
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                                                                                   ~^
      |                                                                                    |
      |                                                                                    unsigned int
      |                                                                                   %lu
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:21: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 10 has type ‘DWORD’ {aka ‘long unsigned int’} [-Wformat=]
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  176 |                     myerrno, strerror(myerrno), win_error);                                                  \
      |                                                 ~~~~~~~~~
      |                                                 |
      |                                                 DWORD {aka long unsigned int}
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:48:72: note: in definition of macro ‘HERROR’
   48 |         H5E_printf_stack(__FILE__, __func__, __LINE__, maj_id, min_id, __VA_ARGS__);                         \
      |                                                                        ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:86:9: note: in expansion of macro ‘HCOMMON_ERROR’
   86 |         HCOMMON_ERROR(maj, min, __VA_ARGS__);                                                                \
      |         ^~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:174:9: note: in expansion of macro ‘HGOTO_ERROR’
  174 |         HGOTO_ERROR(majorcode, minorcode, retcode,                                                           \
      |         ^~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tinit_float.c:617:9: note: in expansion of macro ‘HSYS_GOTO_ERROR’
  617 |         HSYS_GOTO_ERROR(H5E_DATATYPE, H5E_CANTSET, FAIL, "can't restore floating-point environment");
      |         ^~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Eprivate.h:175:84: note: format string is defined here
  175 |                     "%s, errno = %d, error message = '%s', Win32 GetLastError() = %" PRIu32 "", str,         \
      |                                                                                   ~^
      |                                                                                    |
      |                                                                                    unsigned int
      |                                                                                   %lu
[ 37%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_file.c.obj
[ 37%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_group.c.obj
[ 37%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_link.c.obj
[ 37%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_introspect.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_object.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLnative_token.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLpassthru.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5VLtest.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5VM.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5WB.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5Z.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5Zdeflate.c.obj
[ 38%] Building C object src/CMakeFiles/hdf5-static.dir/H5Zfletcher32.c.obj
[ 39%] Building C object src/CMakeFiles/hdf5-static.dir/H5Znbit.c.obj
[ 39%] Building C object src/CMakeFiles/hdf5-static.dir/H5Zscaleoffset.c.obj
[ 39%] Building C object src/CMakeFiles/hdf5-static.dir/H5Zshuffle.c.obj
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5T.c: In function ‘H5T__create’:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5T.c:3421:35: warning: duplicated ‘if’ condition [-Wduplicated-cond]
 3421 |             else if (sizeof(long) == size)
      |                      ~~~~~~~~~~~~~^~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5T.c:3419:34: note: previously used here
 3419 |             else if (sizeof(int) == size)
      |                      ~~~~~~~~~~~~^~~~~~~
[ 39%] Building C object src/CMakeFiles/hdf5-static.dir/H5Zszip.c.obj
[ 39%] Building C object src/CMakeFiles/hdf5-static.dir/H5Ztrans.c.obj
In file included from /build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5encode.h:23,
                 from /build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5private.h:1636,
                 from /build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Shyper.c:26:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Shyper.c: In function ‘H5S__hyper_span_blocklist’:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Shyper.c:4575:47: warning: conversion from ‘hsize_t’ {aka ‘long long unsigned int’} to ‘unsigned int’ may change value [-Wconversion]
 4575 |                 H5MM_memcpy(*buf, start, rank * sizeof(hsize_t));
      |                                          ~~~~~^~~~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5MMprivate.h:41:43: note: in definition of macro ‘H5MM_memcpy’
   41 | #define H5MM_memcpy(D, S, N) memcpy(D, S, N)
      |                                           ^
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Shyper.c:4583:45: warning: conversion from ‘hsize_t’ {aka ‘long long unsigned int’} to ‘unsigned int’ may change value [-Wconversion]
 4583 |                 H5MM_memcpy(*buf, end, rank * sizeof(hsize_t));
      |                                        ~~~~~^~~~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5MMprivate.h:41:43: note: in definition of macro ‘H5MM_memcpy’
   41 | #define H5MM_memcpy(D, S, N) memcpy(D, S, N)
      |                                           ^
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Zscaleoffset.c: In function ‘H5Z__scaleoffset_get_type’:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Zscaleoffset.c:818:33: warning: duplicated ‘if’ condition [-Wduplicated-cond]
  818 |             else if (dtype_size == sizeof(unsigned long))
      |                      ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Zscaleoffset.c:816:33: note: previously used here
  816 |             else if (dtype_size == sizeof(unsigned int))
      |                      ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Zscaleoffset.c:835:33: warning: duplicated ‘if’ condition [-Wduplicated-cond]
  835 |             else if (dtype_size == sizeof(long))
      |                      ~~~~~~~~~~~^~~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Zscaleoffset.c:833:33: note: previously used here
  833 |             else if (dtype_size == sizeof(int))
      |                      ~~~~~~~~~~~^~~~~~~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tconv_float.c: In function ‘H5T__conv_f_i’:
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tconv_float.c:1015:41: warning: conversion from ‘hssize_t’ {aka ‘long long int’} to ‘ssize_t’ {aka ‘int’} may change value [-Wconversion]
 1015 |                 H5T__bit_shift(int_buf, shift_val, (size_t)0, buf_size * 8);
      |                                         ^~~~~~~~~
/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/src/H5Tconv_float.c:1021:31: warning: conversion from ‘hssize_t’ {aka ‘long long int’} to ‘ssize_t’ {aka ‘int’} may change value [-Wconversion]
 1021 |                 new_msb_pos = msb_pos_s + shift_val;
      |                               ^~~~~~~~~
[ 39%] Linking C static library ../bin/libhdf5.a
[ 39%] Built target hdf5-static
make: *** [Makefile:156: all] Error 2
make: Leaving directory '/build/mingw-w64-hdf5/src/hdf5-hdf5_1.14.6/build-i686-w64-mingw32'
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Build failed, check /run/media/devel/chroot-bs/arch-x86_64/buildservice/build

[xantares]

I think you need the to pick up the update from mingw-w64-libaec-1.1.3-2 to corrrect this problem

[Martchus]

On Windows I only tested with apps where I linked against these libs statically and that worked. (When linking against those not-rebuilt libs statically I suppose the error - if there's was one - would actually already show at link time.)

I'm wondering whether there's an upstream issue for this problem because it sounds like a bug that BC is broken. I'm also wondering how MSYS2 deals with this.

What is the actual concrete error you're getting?

[xantares]

it said "the specified procedure could not be found", I saw this with everything linked dynamically, except for boost where libboost was static but linked to the exe through another dll

[xantares]

in short-term, would it be possible to rebuild at least gettext/gmp/jsoncpp/libtiff/proj/suitesparse ?

[Martchus]

Ok, I triggered a rebuild.

[xantares]

great, thanks

[Martchus]

I'm currently trying to figure out what causes weird crashes with my applications, see Martchus/syncthingtray#352. At this point I'm not quite sure what the culprit is but it might be the most recent OpenSSL update that I've pushed. So I'll remove that for now again.

[xantares]

hi, could you rebuild mingw-w64-protobuf ? (abseil update)

[Martchus]

The protobuf version in my repo is already built against abseil-cpp 20250814.0-1 because I updated/rebuilt everything independently and ahead of what you updated on the AUR. But feel free to check the .BUILDINFO of my packages :-)

[xantares]

hello, I think publishing mingw-w64-eigen 5.0.0 was a mistake, I reverted to 3.4.0 as this does not seem like an actual release eventhough archlinux/extra updated to 5.0 too

[xantares]

yes, and the tag will probably be updated again
so imho it be removed for now, or ceres must be updated too

[xantares]

hi,
it seems eigen 5 is official now, could you rebuild mingw-w64-ceres-solver with it ?

[xantares]

hi, would it be possible to rebuild mingw-w64-ceres-solver once again ? I pushed a small update

[Martchus]

I triggered the build.

[xantares]

thanks