Bug 141381 – [GTK] GMutexLocker build issue

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Philippe Normand]

WebKitGTK 1.7.3 doesn't seem to build on Fedora 21 in JHBuild: http://fpaste.org/182989/09049142/ 

gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)

/home/jjmarin/jhbuild/checkout/webkitgtk-2.7.4/Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp: In member function ‘virtual void WebCore::AudioSourceProviderGStreamer::provideInput(WebCore::AudioBus*, size_t)’:
/home/jjmarin/jhbuild/checkout/webkitgtk-2.7.4/Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp:153:5: error: ‘GMutexLocker {aka void}’ is not a template
     GMutexLocker<GMutex> lock(m_adapterMutex);
     ^
/home/jjmarin/jhbuild/checkout/webkitgtk-2.7.4/Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp:153:45: error: variable or field ‘lock’ declared void
     GMutexLocker<GMutex> lock(m_adapterMutex);
                                             ^

[Marcos Chavarría Teijeiro (irc: chavaone)]

I've got a related problem:

In file included from ../../Source/WTF/wtf/gobject/GThreadSafeMainLoopSource.cpp:32:0:
../../Source/WTF/wtf/gobject/GMutexLocker.h:100:12: error: ‘GMutexLocker’ is already declared in this scope
 using WTF::GMutexLocker;
            ^
If I comment that line I got the "GMutexLocker is not a template problem" :S

[Juanjo Marin]

Marcos is right. I totally forgot that I had that messsage before and I commented that line.

I have the impression this error is related with the addition of GMutexLocker in Glib 

https://git.gnome.org/browse/glib/commit/?id=1404d3e12819b342fda74d082dcb067a029141b1

[Philippe Normand]

So I guess we need to rename ours now :)

[Xabier Rodríguez Calvar]

(In reply to comment #3)
> So I guess we need to rename ours now :)

As a first step can be a good idea. Ideally, I guess we could remove ours and use GLib's.

[Carlos Garcia Campos]

(In reply to comment #4)
> (In reply to comment #3)
> > So I guess we need to rename ours now :)
> 
> As a first step can be a good idea. Ideally, I guess we could remove ours
> and use GLib's.

I don't think so, the glib one is not portable, because it depends on compiler features, ours is C++ 11.

[Carlos Garcia Campos]

Created attachment 246313 [details]
Patch

[Carlos Garcia Campos]

Committed r179866: <http://trac.webkit.org/changeset/179866>