After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 667806 - [regression] cyclic dependency in glib/dbus build
[regression] cyclic dependency in glib/dbus build
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.31.x
Other Linux
: Normal critical
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-01-12 19:22 UTC by David Ronis
Modified: 2012-04-25 19:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build: Add --disable-modular-tests build option (4.06 KB, patch)
2012-01-13 15:11 UTC, Colin Walters
reviewed Details | Review
build: Add --disable-modular-tests build option (4.30 KB, patch)
2012-04-12 15:46 UTC, Colin Walters
committed Details | Review
build: When cross compiling, don't require host binaries if tests are not enabled (1.10 KB, patch)
2012-04-12 17:56 UTC, Colin Walters
committed Details | Review
build: Fix 'make dist' regression (1.83 KB, patch)
2012-04-25 19:08 UTC, Colin Walters
committed Details | Review

Description David Ronis 2012-01-12 19:22:34 UTC
I'm building on a slackware 13.37 box, using a heavily modified garnome (I keep it current with gnome).  What this means is that a separate install directory structure is uses for the results of the garnome build and garnome's build scripts know how to specify them to configure etc.   

I recently upgraded glib to version 2.31.8 and have dbus-1.5.8.    If I start from a clean build, 
the makefile of the former picks up the system dbus-1 in /usr/lib while the latter picks up the system glib.   This results in unresolved externals.   For example in the test programs in dbus; I cheated, and didn't build them, but other build components still die (e.g., colord, upowerd).    The bottom line is that one of these two packages shouldn't need the other to build.

Here's a typical problem (in upowerd):

libtool: link: /usr/bin/gcc -Wall -Wcast-align -Wno-uninitialized -Wmissing-declarations -Wpointer-arith -Wcast-align -Wwrite-strings -Winit-self -Wreturn-type -Wformat-nonliteral -Wformat-security -Wmissing-format-attribute -Wsign-compare -O -Wuninitialized -Waggregate-return -Wdeclaration-after-statement -Wno-strict-aliasing -I/opt/garnome-3.3.3/include -O2 -g -pipe -Wl,--as-needed -Wl,--export-dynamic -o .libs/upowerd upowerd-up-polkit.o upowerd-up-daemon.o upowerd-up-device.o upowerd-up-device-list.o upowerd-up-qos.o upowerd-up-config.o upowerd-up-kbd-backlight.o upowerd-up-wakeups.o upowerd-up-history.o upowerd-up-main.o upowerd-up-marshal.o  -L/opt/garnome-3.3.3/lib -lm /opt/garnome-3.3.3/lib/libpolkit-gobject-1.so ../libupower-glib/.libs/libupower-glib.so /opt/garnome-3.3.3/lib/libdbus-glib-1.so /opt/garnome-3.3.3/lib/libgio-2.0.so /opt/garnome-3.3.3/lib/libgmodule-2.0.so -ldl -lz -lresolv /opt/garnome-3.3.3/lib/libdbus-1.so linux/.libs/libupshared.a /usr/lib/libusb-1.0.so /usr/lib/libgudev-1.0.so /usr/lib/libudev.so /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so /opt/garnome-3.3.3/lib/libgobject-2.0.so /opt/garnome-3.3.3/lib/libgthread-2.0.so /opt/garnome-3.3.3/lib/libffi.so /opt/garnome-3.3.3/lib/libglib-2.0.so /opt/garnome-3.3.3/lib/libiconv.so -lpthread -lrt -pthread -Wl,-rpath -Wl,/opt/garnome-3.3.3/lib
upowerd-up-main.o: In function `main':
/home/ronis/Project/notar/GNOME/garnome/freedesktop/upower/work/main.d/upower-0.9.15/src/up-main.c:273: undefined reference to `g_unix_signal_add_full'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_variant_dup_objv'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_variant_take_ref'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cond_clear'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_variant_new_objv'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_value_get_schar'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cond_broadcast'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_environ_getenv'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_unix_set_fd_nonblocking'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_queue_free_full'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_private_set'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_mutex_init'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_rec_mutex_lock'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_environ_setenv'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_mutex_trylock'
/opt/garnome-3.3.3/lib/libpolkit-gobject-1.so: undefined reference to `g_mutex_unlock'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_main_context_ref_thread_default'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_weak_ref_set'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cond_wait'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cond_init'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_weak_ref_get'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_value_set_schar'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_thread_new'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cond_signal'
/opt/garnome-3.3.3/lib/libpolkit-gobject-1.so: undefined reference to `g_mutex_lock'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_rec_mutex_unlock'
/opt/garnome-3.3.3/lib/libgmodule-2.0.so: undefined reference to `g_private_replace'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_mutex_clear'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_cclosure_marshal_generic'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_private_get'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `g_environ_unsetenv'
/opt/garnome-3.3.3/lib/libgio-2.0.so: undefined reference to `glib__private__'
collect2: ld returned 1 exit status

Note the /usr/lib/libglib-2 etc instances.
Comment 1 Matthias Clasen 2012-01-12 20:10:44 UTC
not a glib bug here, afaics. Also, dbus doesn't depend on glib.
Comment 2 David Ronis 2012-01-13 00:04:53 UTC
You may be right, but the generated dbus makefile contains:

DBUS_GLIB_CFLAGS = -I/opt/garnome-3.3.3/include/dbus-1.0 -I/opt/garnome-3.3.3/lib/dbus-1.0/include -I/opt/garnome-3.3.3/include/glib-2.0 -I/opt/garnome-3.3.3/lib/glib-2.0/include  

DBUS_GLIB_LIBS = -L/opt/garnome-3.3.3/lib -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 GLIB_CFLAGS = -pthread -I/opt/garnome-3.3.3/include/glib-2.0 -I/opt/garnome-3.3.3/lib/glib-2.0/include  

GLIB_LIBS = -L/opt/garnome-3.3.3/lib -lgio-2.0 -lgobject-2.0 -lglib-2.0  

Nonetheless, it seems that the problem stems from libgudev.  Making a custom one for the gnome tree "fixes" the problem (The -L flags in the dbus Makefile now are correct, as shown above)

If you think the declarations in the makefile aren't a problem, please clost this.
Comment 3 Colin Walters 2012-01-13 01:16:52 UTC
It's only a test circular dependency.  You can disable tests dbus (--disable-modular-tests), and we should add a configure option to glib to disable tests too.
Comment 4 Colin Walters 2012-01-13 15:11:44 UTC
Created attachment 205210 [details] [review]
build: Add --disable-modular-tests build option

This allows builders to optionally cut the circular dependency between
dbus and glib by disabling the modular tests (just like how the tests
can be disabled in dbus).

It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree.
Comment 5 Matthias Clasen 2012-01-13 15:43:35 UTC
Review of attachment 205210 [details] [review]:

I just don't understand whats 'modular' about our tests.

Do we have to add --enable-tests to DISTCHECK_CONFIGURE_ARGS ?

::: Makefile.am
@@ +13,3 @@
+else
+DIST_SUBDIRS += tests
+endif

Looks to me like this will mke DIST_SUBDIRS miss tests if BUILD_MODULAR_TESTS is on ?
Comment 6 Colin Walters 2012-01-13 20:03:55 UTC
(In reply to comment #5)
> Review of attachment 205210 [details] [review]:
> 
> I just don't understand whats 'modular' about our tests.

Ahh...i just took the name from what smcv did for dbus.  But dbus has unit tests embedded in the source code which are separate from test binaries that *could* run against an installed dbus.

> Do we have to add --enable-tests to DISTCHECK_CONFIGURE_ARGS ?

No, it's on by default.

> ::: Makefile.am
> @@ +13,3 @@
> +else
> +DIST_SUBDIRS += tests
> +endif
> 
> Looks to me like this will mke DIST_SUBDIRS miss tests if BUILD_MODULAR_TESTS
> is on ?

It doesn't need to be in DIST_SUBDIRS if it's in SUBDIRS.
Comment 7 Matthias Clasen 2012-01-15 18:10:27 UTC
Review of attachment 205210 [details] [review]:

Maybe --disable-tests is useful, but I wonder why we don't just fix the existing attempt at disabling some tests if dbus is not available - see HAVE_DBUS1 in gio/tests/Makefile.am

::: configure.ac
@@ +233,3 @@
+              AC_HELP_STRING([--enable-modular-tests],
+                             [build test programs]),,
+              enable_modular_tests=yes)

If the default is yes, then it should be documented as --disable-tests, I think
Comment 8 Matthias Clasen 2012-01-15 18:14:54 UTC
just tested: glib builds fine in the absence of dbus (make check fails, but that is to be expected)
Comment 9 Patrick Welche 2012-01-20 12:50:10 UTC
Another bonus for making it easy to disable tests is losing the build dependency on python. (gdbus-codegen is a python program, but would only be run during the build if tests are on.)
Comment 10 Richard Purdie 2012-02-26 13:18:36 UTC
We (OpenEmbedded/The Yocto Project) have just been running into some issues with glib's dbus dependencies. In our case, we build the system from scratch and want to be able to try and do things in parallel where we can. Having no dbus dependency for glib helps with that as glib can build sooner without waiting for dbus.

We noticed dbus was optional for glib but tried to disable it and couldn't without patching configure since another requirement is that our builds be deterministic. Since its being autodetected, that presents a problem for us. I'd therefore love to see a --without-dbus or --disable-dbus option. Being able to turn off tests would also be of interest to us since we don't use them.
Comment 11 Jonh Wendell 2012-04-12 15:00:02 UTC
+1 for this patch:

I'm cross-compiling glib, and stopped at the point it needs *native* glib-genmarshal, glib-compile-schemas and glib-compile-resources. Those tools are only needed for tests purposes. Disabling tests wouldn't require them at configure time (the patch still needs to do that).

Thus the machine cross-building glib doesn't need to have those binaries (and their dependencies) installed.
Comment 12 Colin Walters 2012-04-12 15:46:08 UTC
Created attachment 211943 [details] [review]
build: Add --disable-modular-tests build option

This patch solves two problems:

First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).

Second, the tests are entirely pointless to build if cross-compiling.

It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
Comment 13 Colin Walters 2012-04-12 15:46:56 UTC
Comment on attachment 205210 [details] [review]
build: Add --disable-modular-tests build option

Updated per review to say --disable (because the default is on)
Comment 14 Jonh Wendell 2012-04-12 15:50:01 UTC
Colin, could you update it so that it doesn't check for glib-genmarshal,... in configure.ac when tests are disabled?
Comment 15 Colin Walters 2012-04-12 16:38:18 UTC
(In reply to comment #14)
> Colin, could you update it so that it doesn't check for glib-genmarshal,... in
> configure.ac when tests are disabled?

Hmm...I don't have a truly cross environment handy right now, so I'd much prefer to review a patch that's been tested by someone with one.

Care to try formulating a patch on top of mine?
Comment 16 Colin Walters 2012-04-12 17:56:36 UTC
Created attachment 211945 [details] [review]
build: When cross compiling, don't require host binaries if tests are not enabled

These binaries are now only used by the test suite.  glib-genmarshal
*used* to be required to generate marshallers, but isn't anymore now
that we use libffi (via g_cclosure_marshal_generic).
Comment 17 Colin Walters 2012-04-15 15:18:21 UTC
Attachment 211943 [details] pushed as f084b60 - build: Add --disable-modular-tests build option
Attachment 211945 [details] pushed as 4b98c51 - build: When cross compiling, don't require host binaries if tests are not enabled
Comment 18 Richard Purdie 2012-04-15 15:25:31 UTC
Thanks, looking forward to updating to this version now in the Yocto Project/OpenEmbedded! :)
Comment 19 Colin Walters 2012-04-25 19:08:25 UTC
Created attachment 212830 [details] [review]
build: Fix 'make dist' regression

Commit f084b603771f78126bc0b07229a1574b76e776bb incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am.  In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Comment 20 Colin Walters 2012-04-25 19:44:05 UTC
Comment on attachment 212830 [details] [review]
build: Fix 'make dist' regression

Attachment 212830 [details] pushed as 063ec9a - build: Fix 'make dist' regression