GNOME Bugzilla – Bug 668765
Error compiling: undefined symbol: g_mutex_lock
Last modified: 2012-02-03 08:02:43 UTC
gda-xa-transaction.c: In function 'gda_xa_transaction_commit': gda-xa-transaction.c:564:6: warning: 'cnc' may be used uninitialized in this function [-Wuninitialized] gda-xa-transaction.c:539:7: warning: 'cnc' may be used uninitialized in this function [-Wuninitialized] gda-xa-transaction.c:509:7: warning: 'cnc' may be used uninitialized in this function [-Wuninitialized] gda-xa-transaction.c:475:6: warning: 'cnc' may be used uninitialized in this function [-Wuninitialized] CC gda-data-pivot.lo CCLD libgda-5.0.la GISCAN Gda-5.0.gir /home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/Gda-5.0.c: In function ‘main’: /home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/Gda-5.0.c:577:3: warning: ‘g_thread_init’ is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:259) [-Wdeprecated-declarations] /home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/.libs/lt-Gda-5.0: symbol lookup error: /home/alien/Projects/libgda-5.0.3/libgda/.libs/libgda-5.0.so.4: undefined symbol: g_mutex_lock Command '['/home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/Gda-5.0', '--introspect-dump=/home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/functions.txt,/home/alien/Projects/libgda-5.0.3/libgda/tmp-introspect1lP5WU/dump.xml']' returned non-zero exit status 127
Which versions of gobject-introspection and glib2 are installed?
My bug #667382 might be related.
My dist is Fedora 16 glib 2.31.12 from master gobject-introspection 1.30 from repo
Funny thing i tried to compile gobject-introspection last version from source, and get the following: ... CC libgiscanner_la-scannerparser.lo CCLD libgiscanner.la CC _giscanner_la-giscannermodule.lo CCLD _giscanner.la CC g_ir_compiler-compiler.o CCLD g-ir-compiler CC g_ir_generate-generate.o CCLD g-ir-generate CC cmph_bdz_test-cmph-bdz-test.o CCLD cmph-bdz-test CC gthash_test-gthash.o CC gthash_test-gthash-test.o CCLD gthash-test CC gi_dump_types-gdump.o CC gi_dump_types-gi-dump-types.o CCLD gi-dump-types CC glib_print-glib-print.o CCLD glib-print GEN g-ir-scanner GEN g-ir-annotation-tool GEN g-ir-doc-tool GISCAN GLib-2.0.gir /home/alien/Projects/gobject-introspection-1.31.10/tmp-introspectMqZjvL/GLib-2.0: symbol lookup error: /home/alien/Projects/gobject-introspection-1.31.10/tmp-introspectMqZjvL/GLib-2.0: undefined symbol: g_bytes_get_type Command '['/home/alien/Projects/gobject-introspection-1.31.10/tmp-introspectMqZjvL/GLib-2.0', '--introspect-dump=/home/alien/Projects/gobject-introspection-1.31.10/tmp-introspectMqZjvL/functions.txt,/home/alien/Projects/gobject-introspection-1.31.10/tmp-introspectMqZjvL/dump.xml']' returned non-zero exit status 127 make[2]: *** [GLib-2.0.gir] Error 1 make[2]: Leaving directory `/home/alien/Projects/gobject-introspection-1.31.10' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/alien/Projects/gobject-introspection-1.31.10' make: *** [install] Error 2
In commit d5e55c0858cb481eb455b03dd87dd0275f589c39, the g_mutex_lock symbol is not called anymore, starting from GLib version 2.31.7. As you have version 2.31.12 it should be Ok (I have 2.31.13 as of tonight). Can you check (in the generated Makefiles) your building environment does not make Libgda use GLib's headers from the GLib installed be Fedora (while linking with the JHBuild ones)?
I think this is an issue on Gda-5.0.gir generation because gthread.h in 2.30 and 2.31 are far different. GObject Introspection 1.31 can parse 2.31 but 1.30 can't, and if you try to use Vala bindings the problem is more critical due to g_mutext use in it. I recommend for now: a) Use 5.0.3 with GLib 2.30 and GI 1.30 b) If you don't plan to use GI, may you need to disable it.
So you might need to increase the requirement in configure.
I found that valac 0.15.1 has added deprecated symbols in 2.32, because I haven't a JHBuild environment I can't reproduce this bug. Could any one check if this bug is fixed using that valac's version? I'll search a way to create a JHBuild environment (without breaking my box) to track this bugs and check there's no problems with upcomming GLib 2.32 and Vala bidings in GDA. Suggestions welcome.
Yes, that seems to work. Thanks. I have increased the dependency in configure.ac: http://git.gnome.org/browse/libgda/commit/?id=6335684bf8a179f7f36fe9a475fc5e968ec05b66 And I've pushed that to the LIBGDA_5_0 branch too. Note that it only checks for the version of libvala-*, and doesn't seem to care about the version of the vapigen command-line tool, though it probably should. But libgda can't be the only project that does this. The build also changes generated files that are in git, though I did not commit those changes. I still think it is unacceptable to put generated files in git.
I'm figuring out what is better, leave or not generated files. For now, with them in the repository, I can find if code changes produce API breaks for bindings by inspecting GIR or (more easy to read) VAPI files. If you inspect your generated GIR file (I assume you are using GI 1.31.x), you can find that Gda.DataProxy.new is not longer a function but a constructor with different syntax, producing an API break for bindings. See bug 667837.
I understand that it can give you a helpful hint, but it's just annoying for everyone else, particularly for people trying to provide (unrelated) patches. Hopefully you can find another way to do the comparison. No-generated-files-in-git is just a strict rule, in my opinion. But I am not the maintainer.