GNOME Bugzilla – Bug 327022
glibmm-2.8.3 fails to compile against glib-2.9.2
Last modified: 2006-01-17 11:27:25 UTC
glibmm fails to compile against glib-2.9.2 System: G4 PowerMac running YDL-4.0.1, an FC2 clone,, gcc-3.3.3, garnome-2.13.4+ The problem file is ./glib/glibmm/thread.cc thread.cc: In member function `void Glib::StaticMutex::lock()': thread.cc:162: error: invalid conversion from `_GMutex**' to `void* volatile*' thread.cc: In member function `bool Glib::StaticMutex::trylock()': thread.cc:167: error: invalid conversion from `_GMutex**' to `void* volatile*' thread.cc: In member function `void Glib::StaticMutex::unlock()': thread.cc:172: error: invalid conversion from `_GMutex**' to `void* volatile*' thread.cc: In member function `Glib::StaticMutex::operator Glib::Mutex&()': thread.cc:194: error: invalid conversion from `_GMutex**' to `void* volatile*' thread.cc: In constructor `Glib::RecMutex::RecMutex()': thread.cc:269: error: invalid conversion from `_GMutex**' to `void* volatile*' thread.cc: In constructor `Glib::RWLock::RWLock()': thread.cc:326: error: invalid conversion from `_GMutex**' to `void* volatile*' The source of the problem can be traced to a change in the glib macros. Whether or not this is a glibmm bug or a glib bug is unknown [to me] at this point. Hopefully this issue can be brought to closure. I worked around this problem by modifying include/glib-2.0/glib/gthread.h Specifically, --- gthread.h 2006-01-14 19:24:21.000000000 -0500 +++ gthread.h.new 2006-01-14 18:57:40.000000000 -0500 @@ -138,7 +138,7 @@ GMutex* g_static_mutex_get_mutex_impl (GMutex **mutex); #define g_static_mutex_get_mutex_impl_shortcut(mutex) \ - (g_atomic_pointer_get (mutex) ? *(mutex) : \ + (g_atomic_pointer_get ((gpointer*)mutex) ? *(mutex) : \ g_static_mutex_get_mutex_impl (mutex)) The cast in g_atomic_pointer_get() (gpointer*)mutex existed in previous versions of glib and was removed recently http://cvs.gnome.org/viewcvs/glib/glib/gthread.h?r1=1.24&r2=1.25 If this change was intentional to enforce stricter API compliance, then the probem is with the glibmm code, for example, void StaticMutex::lock() { g_static_mutex_lock(&gobject_); } Thoughts??? -Joseph
Yes, while the implicit cast might be allowed in C, it's not allowed from C++. This seems to be have been done as part of this change in glib: " 2005-12-27 Matthias Clasen <mclasen@redhat.com> Fix #316221, Michal Benes, Stanislav Brabec; * configure.in: Fix a strict aliasing problem in g_static_mutex_get_mutex(). * glib/gthread.h: ...and in g_static_mutex_get_mutex_impl_shortcut(). "
Yes... Any thoughts on how to resolve this problem? -Joseph
See also bug #316221
Does (gpointer*)mutex issue warning? If yes, you can try (gpointer*)(void*)mutex. This hides strict-aliasing warnings (but not resolve, if there are any).
why again does removing the cast fix the strict-aliasing issues ? This whole area of the language seems very shady to me...
Stanislav, (gpointer*)mutex cast produces no warnings when ./glib/glibmm/thread.cc is compiled. I have noticed that the removal of this cast in gthread.h version 1.25 breaks other applications within the GNOME suite, for example gnet-2.07. -Joseph
I have added the double cast (gpointer*)(void*) now.
Good... I will incorporate the patch into GARNOME -Joseph
glib was compiled without strict-aliasing warnings even before. But third party application have had strict-aliasing problems - see example code from bug 316221. So if this code compiles without warning and it helps for C++ code, it should be OK. In general, double cast hides all strict-aliasing warnings, so we should use it with extreme care, when we are sure, that the code conforms with strict-aliasing rules. But I think it's OK here.