Created attachment 234141 [details] Build log of WebKit revision 170584 on FreeBSD I tried to build WebKitGTK+ trunk on FreeBSD 10.0-RELEASE with Clang 3.3 in the base system, but there are many errors.
Created attachment 234462 [details] Build log of WebKit revision 170826 on FreeBSD
The AtomicStringHash errors in the first log have been fixed. The remaining errors are about GstMpegTsSection and similar API, which has probably been renamed recently to GstMpegts* since you're building with GStreamer 1.3.90 while the Jhbuild environment is providing 1.2.1.
(In reply to comment #2) > The remaining errors are about GstMpegTsSection and similar API, > which has probably been renamed recently to GstMpegts* since you're > building with GStreamer 1.3.90 while the Jhbuild environment is > providing 1.2.1. Yes, that seems to be the case: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=22dfd9aef361c6e630fe32d6b7f6c07588a2dff9 Is that new API stable? Are they not providing any sort of backward compatibility?
The API implemented is -bad is unstable, usually. Until it gets moved to -good or -base.
(In reply to comment #4) > The API implemented is -bad is unstable, usually. Until it gets > moved to -good or -base. Debian and Ubuntu are currently shipping the 1.2.x branch, should we try to support both APIs in the WebKitGTK+ side, or just one of them? I guess that the API might change again before 1.4.0 is released?
I don't think the API is expected to change at this point, 1.3.90 is a pre-release of 1.4.0. So I think we should fix the build for 1.3.90 and disable this code for GStreamer 1.2.x
(In reply to comment #6) > So I think we should fix the build for 1.3.90 and disable this code for GStreamer 1.2.x The problem is that there's at least two major distros that are only shipping 1.2.x at the moment.
The code is already guarded by USE(GSTREAMER_MPEGTS) and that checks for gstreamer-mpegts >= 1.3 in FindGStreamer.cmake. So yeah, let's just adapt our code to the 1.3.90 API, ok?
Created attachment 234631 [details] Build log of WebKit revision 170915 on FreeBSD with GStreamer issue resolved
(In reply to comment #9) > ../../lib/libWebCoreGTK.a(ViewportStyleResolver.cpp.o): In function `WebCore::ViewportStyleResolver::getViewportArgumentValue(WebCore::CSSPropertyID) const': > /home/lantw44/gnome/source/webkit-trunk/Source/WebCore/css/ViewportStyleResolver.cpp:(.text+0x3fd): undefined reference to `WebCore::Node::renderStyle() const' Does the problem disappear if you include NodeRenderStyle.h in ViewportStyleResolver.cpp?
(In reply to comment #10) > (In reply to comment #9) > > ../../lib/libWebCoreGTK.a(ViewportStyleResolver.cpp.o): In function `WebCore::ViewportStyleResolver::getViewportArgumentValue(WebCore::CSSPropertyID) const': > > /home/lantw44/gnome/source/webkit-trunk/Source/WebCore/css/ViewportStyleResolver.cpp:(.text+0x3fd): undefined reference to `WebCore::Node::renderStyle() const' > > Does the problem disappear if you include NodeRenderStyle.h in ViewportStyleResolver.cpp? This problem is already resolved in trunk, but there is another problem: [ 95%] Generating ../../WebKit2-3.0.gir /usr/bin/ld: cannot find -lintl clang: error: linker command failed with exit code 1 (use -v to see invocation) linking of temporary binary failed: Command '['/usr/bin/clang', '-o', '/home/lantw44/gnome/source/webkit-trunk-build/Source/WebKit2/tmp-introspectpnE48g/WebKit2-3.0', '-Wno-deprecated-declarations', '/home/lantw44/gnome/source/webkit-trunk-build/Source/WebKit2/tmp-introspectpnE48g/WebKit2-3.0.o', '-L.', '-Wl,-rpath=.', '-Wl,--no-as-needed', '-lwebkit2gtk-3.0', '-ljavascriptcoregtk-3.0', '-L/home/lantw44/gnome/source/webkit-trunk-build/lib', '-Wl,-rpath=/home/lantw44/gnome/source/webkit-trunk-build/lib', '-Wl,--export-dynamic', '-lgmodule-2.0', '-pthread', '-lgtk-3', '-lgdk-3', '-lpangocairo-1.0', '-lpango-1.0', '-latk-1.0', '-lcairo-gobject', '-lcairo', '-lgdk_pixbuf-2.0', '-lsoup-2.4', '-lgio-2.0', '-lgobject-2.0', '-L/home/lantw44/gnome/devinstall/lib', '-lglib-2.0', '-lintl']' returned non-zero exit status 1 *** Error code 1 libintl is installed in /usr/local/lib, and the LDFLAGS environment variable is set to `-L/home/lantw44/gnome/devinstall/lib -L/usr/local/lib' by jhbuild.
Created attachment 234859 [details] Build log of WebKit revision 171064 on FreeBSD with GStreamer issue resolved
Can you please provide the patch for GStreamer build fixes?
Created attachment 234863 [details] GStreamer 1.3.90 build fixes for WebKit trunk
Comment on attachment 234863 [details] GStreamer 1.3.90 build fixes for WebKit trunk Thanks! Would you mind providing a ChangeLog entry? This page is quite helpful for new contributors http://www.webkit.org/coding/contributing.html
(In reply to comment #15) > (From update of attachment 234863 [details]) > Thanks! Would you mind providing a ChangeLog entry? This page is quite helpful for new contributors http://www.webkit.org/coding/contributing.html Do we have to keep compatibility with older version of GStreamer?
(In reply to comment #16) > (In reply to comment #15) > > (From update of attachment 234863 [details] [details]) > > Thanks! Would you mind providing a ChangeLog entry? This page is quite helpful for new contributors http://www.webkit.org/coding/contributing.html > > Do we have to keep compatibility with older version of GStreamer? Not in this case, that code is enabled only if gstreamer-mpegts >= 1.4.0 is found. See the cmake file mentioned in the comments above.
I mention in comment 8 that 1.3 is checked, we'd need 1.4 there, :)
Created attachment 235066 [details] Build fixes for GStreamer >= 1.3.90
(In reply to comment #19) > Created an attachment (id=235066) [details] > Build fixes for GStreamer >= 1.3.90 For this we have a patch that conditionally typedefs the GstMpegTs* types (see bug #135114). I think that approach is better because it will allow to keep using the previous GStreamer version, which can be important for downstream projects using WebKit{GTK,EFL}.
I uses LDFLAGS="-Wl,-Y/usr/local/lib" to specify the location of libintl, but LDFLAGS is unset in Source/WebKit2/PlatformGTK.cmake when running g-ir-scanner. Therefore, I gets this error: /usr/bin/ld: cannot find -lintl Is there any reason to ignore LDFLAGS set by the user?
Created attachment 235943 [details] Disable memory sampler on non-Linux system It seems Source/WebKit2/Shared/linux/WebMemorySamplerLinux.cpp only works on Linux because it uses many Linux-specific features, so we should disable memory sampler on other systems by default.
Comment on attachment 235943 [details] Disable memory sampler on non-Linux system Looks good but would you mind providing a ChangeLog? The full procedure for code contributions is described there: http://www.webkit.org/coding/contributing.html
Created attachment 236600 [details] Disable memory sampler on non-Linux system (with ChangeLog)
Committed r172623: <http://trac.webkit.org/changeset/172623>
The LDFLAGS problem has not been solved ...
Comment on attachment 236600 [details] Disable memory sampler on non-Linux system (with ChangeLog) Rejecting attachment 236600 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 236600, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: code: 1 cwd: /Volumes/Data/EWS/WebKit Parsed 2 diffs from patch file(s). patching file ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file Source/cmake/OptionsGTK.cmake Hunk #1 succeeded at 102 with fuzz 1 (offset 6 lines). Hunk #2 FAILED at 139. 1 out of 2 hunks FAILED -- saving rejects to file Source/cmake/OptionsGTK.cmake.rej Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Philippe Normand']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output: http://webkit-queues.appspot.com/results/5198761936551936
Please open a new bug or clone this one. We usually deal with one patch per bug.