
On Fri, Sep 27, 2019 at 06:17:24PM +0100, Daniel P. Berrangé wrote:
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative memory allocator, so mixing g_malloc/g_free with malloc/free was not safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1 Author: Alexander Larsson <alexl@redhat.com> Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no longer a mandatory requirement for correctness, just stylistic. This is explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must do this by linking to a library that replaces the core malloc/free implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of g_malloc/g_free causing an ABI change in the public libary, and can avoid memory copying when talking to external libraries.
This patch probes for glib, gobject and gio. Glib provides the foundation layer with a collection of data structures, helper APIs, and platform portability logic. GObject provides the object type system, built on glib. GIO builds on GObject, providing objects for various interesting tasks, most notably including DBus client and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- m4/virt-glib.m4 | 4 ++-- src/Makefile.am | 2 ++ src/internal.h | 1 + src/lxc/Makefile.inc.am | 2 ++ src/remote/Makefile.inc.am | 1 + src/util/Makefile.inc.am | 1 + tests/Makefile.am | 3 ++- tools/Makefile.am | 1 + 8 files changed, 12 insertions(+), 3 deletions(-)
I would not link to gio for now as it's not used by this series, we can introduce it later once there is a need for it. Reviewed-by: Pavel Hrdina <phrdina@redhat.com>