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 316079 - MinGW compilation: G_LOCK and G_UNLOCK break strict-aliasing
MinGW compilation: G_LOCK and G_UNLOCK break strict-aliasing
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 316073
 
 
Reported: 2005-09-12 13:13 UTC by Michal Benes
Modified: 2005-11-14 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michal Benes 2005-09-12 13:13:43 UTC
I am getting the following warning on G_LOCK:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_GNU_SOURCE -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -fno-common -g
-Wall -Werror -DGST_DISABLE_DEPRECATED -I..
-DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\"0.9\" -g -O2 -MT
libgstreamer_0.9_la-gstobject.lo -MD -MP -MF
.deps/libgstreamer_0.9_la-gstobject.Tpo -c gstobject.c  -DDLL_EXPORT -DPIC -o
.libs/libgstreamer_0.9_la-gstobject.o
gstobject.c: In function `gst_object_set_name_default':
gstobject.c:594: warning: dereferencing type-punned pointer will break
strict-aliasing rules
gstobject.c:605: warning: dereferencing type-punned pointer will break
strict-aliasing rules

These are "only" warnings but -Werror flag causes the compilation to stop.

A am using glib-2.6.5
Comment 1 Michael Smith 2005-09-13 14:16:05 UTC
I've encountered a number of cases where gcc4 badly miscompiles things if you
ignore this warning, for what it's worth - the new optimisation infrastructure
is much more agressive and relies heavily on the aliasing information. So fixing
this sort of issue is generally pretty important.

However, this doesn't seem to be triggering for other people, so there's clearly
something different. Does the win32 version of glib do funny/weird stuff with
the glib mutex definitions? It's more or less impossible to figure out what the
mess of evilly nested macros in the glib header files is actually doing here. 

Anyway, this looks more like a glib issue to me than a gstreamer one - our usage
of these G_LOCK macros looks fine. As a temporary workaround, you can, of
course, disable -Werror for this file.



Comment 2 Michal Benes 2005-09-13 15:46:00 UTC
OK, G_LOCK (object_name_mutex);
expands to
  ((g_threads_got_initialized) ? (*g_thread_functions_for_glib_use . mutex_lock)
 ((((*((gpointer*)&g__object_name_mutex_lock)) ? *(&g__object_name_mutex_lock) :
 g_static_mutex_get_mutex_impl (&g__object_name_mutex_lock)))) : ((void)0));

I have also found that this "type-punned pointer" apears only with -O2 (or
greater). My GCC version is
gcc version 3.4.4 (mingw special)

You are right, it is probably a GLib bug, I will report this to their bugzilla.
Comment 3 Michal Benes 2005-09-13 16:44:30 UTC
I have reported this to GLib developers as bug #316221. I doubt they are going
to fix this soon.

Would it be possible implement some temporary workaround to GStreamer? Perhaps
something like not using -O2 or -Werror in MinGW. 

I think many people will give up if configure; make; make install does not work.
Comment 4 David Schleef 2005-09-13 18:19:29 UTC
-Werror is not used in releases.
Comment 5 Michal Benes 2005-11-14 08:33:48 UTC
This is not GStreamer problem, but a GLib one. It seems they are working on a
solution now.