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(a)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(a)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(a)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(a)redhat.com>