GCC version mismatch? What is the GCC version of the MinGW-w64 cross compiler on Linux? MSYS2 UCRT64 GCC is 14.2.0

BTW, the issue of SVG images still remains:

https://github.com/geany/geany/pull/4094#issuecomment-2525065251

@chadchoi Anyway, since you got the latest version of Geany running, you should be able to test the LSP plugin by getting the artifact from

https://github.com/geany/geany-plugins/actions/runs/12283983695/

and installing geany-plugins from there (no need to install Geany itself, you'd have to fight with the libstdc++ problem again).

As far as I can tell, it works, but I didn't use it for real development so I'm interested in any feedback.

We use the debian cross-compiler

https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/tree/master/debian?r...

for the nightly builds and CI and have to use whatever it ships. I'm actually not sure what variant it is.

@techee It turns out that I was right.

GCC version mismatch? What is the GCC version of the MinGW-w64 cross compiler on Linux? MSYS2 UCRT64 GCC is 14.2.0

MSYS2 UCRT64 GCC is 14.2.0, the latest version of MinGW-w64 cross compiler on Debian is 12.0, see:

https://packages.debian.org/search?keywords=mingw-w64

...

@techee It turns out that I was right.

But how does it matter to the actual problem? The discussion in [msys2/MINGW-packages#22847](https://github.com/msys2/MINGW-packages/issues/22847) and your various comments are pretty off topic. Do you know how to fix the CI builders and fix the librsvg problem or do you have any insight into the problem? If so, I'm all ears. If not, please reduce the amount of noise around.

Which noise? This PR is about fixing the problems of missing dlls, isn't it? We are discussing the problem of the mismatch of two versions of libstdc++. It has nothing to do with the malfunctioning of librsvg!

...

This PR is about fixing the problems of missing dlls, isn't it?

I think you don't understand what's going on. There are 2 problems:

I think it's you that mixing different problems. The problem with librsvg should have its own issue and its own PR. You are reusing this unrelated PR to discussion about it. The discussion about librsvg here is off-topic and you are wrong!

1. Red squares instead of icons - this is caused by the librsvg problem I reported in [[librsvg] svg GDK pixbuf loader doesn't work since October 15 msys2/MINGW-packages#22847](https://github.com/msys2/MINGW-packages/issues/22847). It got introduced by the commit I reported there and I'd like to get a feedback from someone who made the commit or knows more about the build options used. It has nothing to do with "missing librsvg", using, ucrt variant of mingw or whether it works locally on my machine or not.

And it's completely unrelated. The issue I posted, #4084, is about missing of dlls caused Geany to fail to run. This PR is supposed to solve that. This means on this PR you only need to care about the missing dlls to have Geany running. The red squares caused by librsvg is completely unrelated and deserves its own issue and its own PR!

2. Two conflicting versions of libstdc++ - we need the "posix" variant of threads for Geany itself, but the libLerc library, which is now required as a dependency of Geany (which didn't use to be the case before so this problem didn't exist in the past), is built against the win32 thread variant. So we either rebuild libLerc against the "posix thread" variant or, as you suggested, rebuild libtiff without libLerc (or find some other solution). I find it safer to rebuild libLerc because it has no additional dependencies and it's mostly "dead" compared to libtiff which is actively developed and whose development might introduce more problems for us in the future. This is clearly our own problem and I didn't report it to mingw.

Nonsense. The MSYS2 MinGW-w64 are all using POSIX thread model. The mismatch is about different GCC versions, not different thread models!

And it's completely unrelated. The issue I posted, https://github.com/geany/geany/issues/4084, is about missing of dlls caused Geany to fail to run. This PR is supposed to solve that. This means on this PR you only need to care about the missing dlls to have Geany running. The red squares caused by librsvg is completely unrelated and deserves its own issue and its own PR!

Well, we don't have a separate issue for that so I discussed it here.

Nonsense. The MSYS2 MinGW-w64 are all using POSIX thread model. The mismatch is about different GCC versions, not different thread models!

You are simply wrong. By default, mingw libstdc++ uses the win32 thread model. @eht16 had to start using the "posix" variant of libstdc++ in https://github.com/geany/geany/commit/354c7ba4e66803f16d9e0452b7829d47cb7425... because Scintilla started using some features that require it. However, now, Geany also has the libLerc dependency and that library was build against the standard win32 thread libstdc++ so there are mismatches between symbols. For more, see e.g.

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win3...

@chadchoi I'm ending all discussions with you by this - explaining things over and over to you is tedious and, more importantly, I don't like your behavior. You simply don't know much, based on your github profile you are very new to open source development but behave as if you knew everything best (typical sign of not knowing much). My advice to you is to change your behavior, otherwise you won't be taken seriously anywhere. Or instead of kicking around, start doing something useful and e.g. provide a patch fixing the problems.

I have unsubscribed. Please don't tag me anymore. Thanks.

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.

...

Do you have any link to some official msys2 documentation stating that the "posix" variant is default?

It really seems to be the case:

https://github.com/msys2/MINGW-packages/blob/9f766f74cef87296b08c4508e12f600...

But the libstdc++ coming from the debian cross compiler differs from the libstdc++ coming from mingw. Not really sure what's going on. In any case we will probably have to compile libLerc by ourselves unless someone has a better solution.

So Github user @chadchoi was right. They said it's not thread models mismatch but libstdc++ versions mismatch. As I know, you can't upgrade your cross compiler because Debian is Debian, they never provide up-to-date packages. Building your own libLerc is the only solution.

So Github user @chadchoi was right. They said it's not thread models mismatch but libstdc++ versions mismatch.

I was apparently wrong in this case, sorry.

librsvg is written in Rust. This is what happens when you introduce Rust into a C project. The binary generated by Rust tends to boom in size. This is normal. I don't think librsvg was linked statically into the loader as you have guessed.

That's clear (I already had my share of issues with this particular library and the macOS port). But there are 2 libraries - the actual librsvg library and the loader which is just a very thin library. I haven't checked in what language the loader is written but on my Debian linux it looks this way - pretty much like all the rest:

``` -rw-r--r-- 1 root root 67640 Jun 13 2024 libpixbufloader-ani.so -rw-r--r-- 1 root root 67656 Jun 13 2024 libpixbufloader-bmp.so -rw-r--r-- 1 root root 67640 Jun 13 2024 libpixbufloader-gif.so -rw-r--r-- 1 root root 67640 Jun 13 2024 libpixbufloader-icns.so -rw-r--r-- 1 root root 67712 Jun 13 2024 libpixbufloader-ico.so -rw-r--r-- 1 root root 67696 Jun 13 2024 libpixbufloader-pnm.so -rw-r--r-- 1 root root 67664 Jun 13 2024 libpixbufloader-qtif.so -rw-r--r-- 1 root root 67376 Jul 30 2023 libpixbufloader-svg.so -rw-r--r-- 1 root root 67648 Jun 13 2024 libpixbufloader-tga.so -rw-r--r-- 1 root root 67648 Jun 13 2024 libpixbufloader-tiff.so -rw-r--r-- 1 root root 67536 Mar 4 2023 libpixbufloader-webp.so -rw-r--r-- 1 root root 67640 Jun 13 2024 libpixbufloader-xbm.so -rw-r--r-- 1 root root 67640 Jun 13 2024 libpixbufloader-xpm.so ```

But of course it's hard to compare, maybe on Windows there's some extra boilerplate code that has to be added.

After checking https://github.com/msys2/MINGW-packages/commit/a2aaa55559c65dfe4b08f30d24299... and subsequent commits in more detail, they switch from autotools to meson and there may be so many things that meson does differently that there's probably no easy way to figure out, what it is.

So while hacky, updating the cache manually will probably be the only option for now.