> 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: https://github.com/msys2/MINGW-packages/issues/22880#issuecomment-2559946964 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 or view it on GitHub: https://github.com/geany/geany/pull/4088#issuecomment-2560252894 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/pull/4088/[email protected]>
