在gobject 的官网上，我们可以看到：
GTK+ 和大多数 GNOME 库使用 GObject 及其较低级别的类型系统 GType 来提供：
- 面向对象的基于 C 语言的 API 和
- 与其他编译或解释语言的自动透明 API 绑定
第一部分对我来说似乎很清楚，但第二部分不是。
确实，在谈到 gobject 和绑定时，引入的概念通常是 gobject-introspection，但据我了解，gobject-introspection 可用于为任何有文档的 C 库创建 .gir 和 .typelib，而不仅仅是基于 gobject图书馆。
因此我想知道是什么让 gobject 特别绑定友好。
据我了解，gobject-introspection 可用于为任何记录的 C 库创建 .gir 和 .typelib，而不仅仅是基于 gobject 的库。
这在实践中并不是真的。您可以做一些非常基本的事情，但您必须手动编写 GIR（而不仅仅是运行一个扫描源代码的程序）。我知道的唯一的是那些与 gobject-introspection 一起分发的（*.gir 文件，*.c 文件是为了避免循环依赖），甚至那些通常也只是 C API 的一个相当小的子集。
至于其他功能，GObject 中的几乎所有功能都有帮助……基本思想是绑定通常需要 RTTI。有一些类型，比如GValue（一个简单的盒子来存储一个值 + 类型信息），GClosure（用于回调），属性和信号用GTypes 来描述自己，等等。如果您使用 GObjects（而不是创建新的基本类型），您将获得有关继承和接口的运行时数据，并且 GObject 奇怪的构造方案甚至允许其他语言对 C 中声明的类型进行子类化。
g-ir-scanner在非 GObject 库上不能真正做很多事情的原因是所有这些信息都丢失了。在扫描源代码寻找注解后，g-ir-scanner实际上会加载编译后的模块并使用 GObject 的 API 来抓取这些信息（这使得交叉编译很痛苦）。换句话说，GObject-Introspection 是一个比你想象的要小得多的项目……它需要的大量数据来自 GObject API。