the error:

    TEST: qdata... (pid=2737915)
    /path/to/src/glib-2.34.2/gobject/tests/.libs/qdata: symbol lookup error: /path/to/src/glib-2.34.2/gobject/.libs/libgobject-2.0.so.0: undefined symbol: g_key_file_unref
    FAIL: qdata
    /bin/bash: line 1: 2737901 Terminated              G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) ../../glib/gtester --verbose qdata boxed enums param signals threadtests dynamictests binding properties reference ifaceproperties valuearray
    make[5]: *** [test-nonrecursive] Error 143

In my case, this meant that an older libglib-2.0.so from the system was being
picked up instead of /path/to/src/glib-2.34.2/glib/.libs/libglib-2.0.so.  This
was due to the value of LD_LIBRARY_PATH that libtool chose for the wrapper
scripts in /path/to/src/glib-2.34.2/gobject/tests.  For more info, see "wrong
LD_LIBRARY_PATH in wrapper scripts",litool mailing list, 2012-11-08
(http://lists.gnu.org/archive/html/libtool/2012-11/msg00009.html).  I couldn't
find any way to get libtool to do the right thing (setting LD_LIBRARY_PATH or
LDFLAGS didn't help), so I ended up making a symbolic link in
/path/to/src/glib-2.34.2/glib/.libs for libffi.so.  This short-circuited
libtools search for that library on the system, and caused the gobject tests to
pick up the correct glib (via the LD_LIBRARY_PATH in the libtool wrappers).

In general, I suggest that glib try to wean itself off libtool, which seems to
be more trouble than it is worth.