RESOLVED FIXED 141381
[GTK] GMutexLocker build issue
https://bugs.webkit.org/show_bug.cgi?id=141381
Summary [GTK] GMutexLocker build issue
Philippe Normand
Reported 2015-02-09 01:07:37 PST
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); ^
Attachments
Patch (15.66 KB, patch)
2015-02-10 00:02 PST, Carlos Garcia Campos
zan: review+
Marcos Chavarría Teijeiro (irc: chavaone)
Comment 1 2015-02-09 01:17:45 PST
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
Comment 2 2015-02-09 01:39:21 PST
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
Comment 3 2015-02-09 01:42:44 PST
So I guess we need to rename ours now :)
Xabier Rodríguez Calvar
Comment 4 2015-02-09 02:04:06 PST
(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
Comment 5 2015-02-09 02:15:55 PST
(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
Comment 6 2015-02-10 00:02:47 PST
Carlos Garcia Campos
Comment 7 2015-02-10 00:16:33 PST
Note You need to log in before you can comment on or make changes to this bug.