Debian offers the MinGW-w64 cross compiler in both POSIX and Win32 thread model variants, and you chose to use the Win32 variant? Well, this is simple. You simply need to switch to use the POSIX variant of the MinGW-w64 cross compiler, easy peasy.

You got it wrong - it's the other way round - we use the posix variant.

Your wording is wrong. You said By default, mingw libstdc++ uses the win32 thread model.. This is simply wrong. The MinGW-w64 cross compiler you chose to use is targeting the Win32 thread model? Right.

No, once again, we use the posix variant.

But MinGW-w64 in general? Nope.

If so, libLerc coming from mingw should work out of the box with Geany's posix libstd++, shouldn't it? Instead, I had to recompile it against the posix libstdc++ to make it work. So I assumed that mingw uses the win32 variant by default. Do you have any link to some official msys2 documentation stating that the "posix" variant is default?

I have no idea why you chose the Win32 thread model variant from the beginning. It's very unpopular. No one uses it. Popular MinGW-w64 distros like winlibs.com doesn't even provide Win32 thread model builds. People all use POSIX thread model for maximum compatibility.

Let's repeat the same sentence again: we don't use the win32 variant.

BTW, Github Actions does provide MSYS2 in their CI. Why don't you simply use that for your Windows builds?

Probably a question for @eht16 (I'm not a maintainer of the Windows build, I don't know much about it. I maintain the macOS port). I assume the build time is lower (see below). Also, we are not Windows developers but Linux developers. The Windows variant in Geany is just a "bonus" and I think anyone here tries to avoid Windows as much as possible.

If you managed to cross compile from Linux, why don't you cross compile everything you need instead of stealing prebuilt libraries from MSYS2 packages?

That's pretty simple - compilation time. We create the Windows installer as part of our CI so every pull request builds the Windows binaries. Imagine how long it would take to cross-compile all the dependencies and we'd probably have to start paying for the CPU time.

Note: The gdk-pixbuf-query-loaders.exe you cross compiled is a Windows binary, you can't run it on Linux so it seems Wine is used.

Yes.

But Wine has problems with bcryptPrimitives.dll. The result is it can't be used to regenerate the loaders cache. If you continue to cross compile from Linux, the only solution is the hack to manually append to loaders.cache you have described.

I don't think there's some general problem with the loaders - the cache-generating binary works all right for all other loaders and there was no problem before for SVG either. But after the October 16 commit I mentioned, this stopped working. What I suspect is going on is this:

msys2/MINGW-packages#22880 (comment)

i.e. that the actual librsvg library gets statically linked to the loader. That explains the huge binary size and also the sudden
bcryptPrimitives.dll dependency which wasn't present before (and was probably only present in the actual librsvg library but not present in the loader).

So I'd like to learn why such a change was made and whether it was intentional. On linux (and macOS too) loaders are small libraries that don't contain the actual library code so this is definitely not a standard way to create them.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.