Seems to be related to his recent libsoup3 update. Indeed libsoup3 seems to be released end of September, and he has it, while my Gentoo Linux does not offer it yet, and my attempt to build and install it from git failed.
So I can not test on my box. And indeed I know nothing about that lib, I think we provided it for Nim as some time ago someone asked for WebKitGtk2 support, and for that libsoup was necessary.
I have /usr/share/gir-1.0/Soup-2.4.gir and for that all is fine, for GTK3 and GTK4. But he has additional Soup-2.4.gir, Soup-3.0.gir, SoupGNOME-2.4.gir and somehow the install fails. One of the error messages is
(process:10775): GLib-GObject-WARNING **: 14:59:28.011: cannot register existing type 'SoupAuth'
(process:10775): GLib-GObject-WARNING **: 14:59:28.011: cannot add private field to invalid (non-instantiatable) type '<invalid>'
(process:10775): GLib-CRITICAL **: 14:59:28.011: g_once_init_leave: assertion 'result != 0' failed
(process:10775): GLib-GObject-CRITICAL **: 14:59:28.011: g_type_register_static: assertion 'parent_type > 0' failed
(process:10775): GLib-GObject-WARNING **: 14:59:28.011: cannot add private field to invalid (non-instantiatable) type '<invalid>'
(process:10775): GLib-CRITICAL **: 14:59:28.012: g_once_init_leave: assertion 'result != 0' failed
So how is version 3.0 related to 2.4? Why does he has v2.4 on his ArchLinux still, when 3.0 is available? For which GTK, 3 or 4, we need which libsoup?
I think the Nim install script https://github.com/StefanSalewski/gintro/blob/master/tests/gen.nim#L4323 should be able to handle that, as we do specify version numbers for some other libs already. Unfortunately the gobject-introspection error messages are not really helpful to learn what exactly is wrong currently.
GTK does not depend on libsoup, and libsoup does not depend on GTK, so it does not matter.
You just need to make sure that you follow Sebastian’s advice and ensure they are never linked together. This is easier said than done currently. GNOME is hoping to transition from libsoup 2 → libsoup 3 for GNOME 42, but we’ll see how it goes.
But when I would change that line, it may fail elsewhere. I was not able to install libsoup 3 on my Gentoo box, so I can not test. Maybe, as I specify in the gen.nim file no explicit version for libsoup, gobject-introspection tries to load both? But in that case, how to fix? How can I know that someone has version 3.0 and wants to use that version, while someone other has only version 2.4?
The problem seems to be related to libnice. When libsoup3 is available, then first processing libnice by gobject-introspection, and then processing libsoup results in trouble:
else:
echo "First we try generating bindings for GTK4, this may fail when GTK4 is not properly installed"
echo "on your computer. But don't worry, you can still use GTK3"
main("Nice")
main("Soup")#, "2.4")
If we specify no version number for libsoup, or specify 3.0, then we get the error. Specifying 2.4 works.
Well this is exactly what we just told you about. You cannot load libsoup2 and and libsoup3 in the same process, so you cannot use libnice and libsoup3 in the same process.
It might “work,” but it doesn’t really work. libnice thinks it is using libsoup 2. Who knows what is actually happening.
But I was not sure that libnice is the one which needs libsoup, and more important, I don’t know what gobject-introspection is doing internally. For some other libs, e.g. for gtksourceview, we needs also one version for old GTK3 and a different one for GTK4. But for gtksourceview we get a message that it can not load that lib when we use the wrong version. For libsoup there are only some error messages, and the whole program hangs, we have to press CTRL-C to terminate it.
My initial idea was, that for systems which have libsoup 3.0 available, we can use always that one. But that is obviously wrong, as libnice currently always needs the old libsoup 2.4. So for the Nim bindings, we should generate a bindings module for libsoup2.4 and try to generate one libsoup3.0 when possible. We already run the whole bindings generation process two times, as gobject-introspection can always load only one lib version, e.g. gtk3 or gtk4, and there is no unload support to start from scratch. So I think I will try to generate the libsoup2.4 bindings in the process where we generate the gtk3 modules, and then try to generate libsoup3.0 in the process where we generate the gtk4 modules.
What makes it more difficult is that in future libnice may need libsoup3. All that is not really easy, as Nim is a statically typed compiled language, and we generate the bindings modules in advance at install time. Some people like Mr. Bassi suggested in the last two years to use the XML gir files instead of gobject-introspection to generate the bindings. Maybe a good advice, but it came 5 years too late, we started with the high level Nim GTK bindings in 2016.
That is what I would hope for. But still using the gobject-introspection API for libnice and libsoup in the same process can give a crash, when libsoup version does not match. See crash massages at the start of this thread.
I guess the most clean solution for that issue would be to relaunch the bindings generator program for each single library, instead to process all GTK4 and all GTK3 related libraries together in one process each. But that would need a large rewrite of the Nim bindings generator program.
The best option would be adding a reset() function to gobject-introspection API to reset its internal state to virgin, but Mr Bassi told me already years ago that that is not provided by gobject-introspection API.
Real problems will occurr when libnice is switching to libsoup3, so some people will have a libnice with libsoup2.4 and some a libnice with libsoup3, and gobject-introspection API will not offer a way to detect that, but may just crash.
That’s also simply not possible with GObject. The library is not unloadable safely, and neither are specific GTypes (even dynamic ones are not fully unloaded).
That’s just how it is unfortunately. You need to have a consistent set of library versions in your process or things will explode.
No, I am not really assuming that. It is just that we have two fully separated processes for the bindings generation. Initially we had only one, but then GTK4 appeared, and we had to split it to two fully separated processes, as gobject-introspection can not process all together. The compiled gen.nim generator script is launched two times, see gintro/gintro.nimble at master · StefanSalewski/gintro · GitHub
First launch is for processing all the libs compatible with GTK4, and second launch is to process all the libs compatible with GTK3.
As we have currently only these two processes, the suggested solution is to process libnice and libsoup2.4 in the GTK3 process, and libsoup3.0 in the GTK4 process. My feeling is that libnice is the only critical module currently, as gobject-introspection loads libsoup when it processes libnice. For all the other libs for which we generate Nim bindings this seems not to happen.
Later, when we have at least a few hundred users, we may rewrite all of that again, or maybe hire someone to do that. But I do not intent to do it in the next five years myself, the total number of GTK users, from all the supported language bindings, is just too small currently. Unfortunately GTK4 has not really improved the situation. Well at least for Rust, Python and plain C there are still some users. For Dlang, Go, Gtkmm, Crystal, Ruby and Nim there are really not many. Maybe for JavaScript there are still a few?
But I don’t really understand it.