libguile-gi.so should not link to a specific version of GObject / GLib, since there is no guarantee that a user will be loading a GObject-using library that links to the same version of GObject that libguile-gi.so did. When those versions differ, pointers and pointer-like numbers like GType can be incorrect. It should wait for the user to load a GObject-using library, then dlopen GObject/GLib.
That can't happen because libguile-gi links to libgirepository which itself links to a specific version of GObject/GLib.
So, split guile-gi into a parser and a runtime. The parser can use libgirepository to create information that describes how to bind a GObject library. The runtime should parse that information and otherwise avoid libgirepository completely.
Basically this is just creating a guile-gi specific intermediate data that acts like GIR XML, without the overhead of parsing large XML files at runtime.
libguile-gi.so should not link to a specific version of GObject / GLib, since there is no guarantee that a user will be loading a GObject-using library that links to the same version of GObject that libguile-gi.so did. When those versions differ, pointers and pointer-like numbers like GType can be incorrect. It should wait for the user to load a GObject-using library, then dlopen GObject/GLib.
That can't happen because libguile-gi links to libgirepository which itself links to a specific version of GObject/GLib.
So, split guile-gi into a parser and a runtime. The parser can use libgirepository to create information that describes how to bind a GObject library. The runtime should parse that information and otherwise avoid libgirepository completely.
Basically this is just creating a guile-gi specific intermediate data that acts like GIR XML, without the overhead of parsing large XML files at runtime.
See bug #96 See discussion #133