Bug 134483 – Fail to build WebKitGTK+ trunk on FreeBSD

• Component: New Bugs
• Status: RESOLVED FIXED

[Ting-Wei Lan]

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.

[Ting-Wei Lan]

Created attachment 234462 [details]
Build log of WebKit revision 170826 on FreeBSD

[Zan Dobersek]

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.

[Alberto Garcia]

(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?

[Philippe Normand]

The API implemented is -bad is unstable, usually. Until it gets moved to -good or -base.

[Alberto Garcia]

(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?

[Philippe Normand]

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

[Alberto Garcia]

(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.

[Philippe Normand]

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?

[Ting-Wei Lan]

Created attachment 234631 [details]
Build log of WebKit revision 170915 on FreeBSD with GStreamer issue resolved

[Alberto Garcia]

(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?

[Ting-Wei Lan]

(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.

[Ting-Wei Lan]

Created attachment 234859 [details]
Build log of WebKit revision 171064 on FreeBSD with GStreamer issue resolved

[Philippe Normand]

Can you please provide the patch for GStreamer build fixes?

[Ting-Wei Lan]

Created attachment 234863 [details]
GStreamer 1.3.90 build fixes for WebKit trunk

[Philippe Normand]

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

[Ting-Wei Lan]

(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?

[Philippe Normand]

(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.

[Philippe Normand]

I mention in comment 8 that 1.3 is checked, we'd need 1.4 there, :)

[Ting-Wei Lan]

Created attachment 235066 [details]
Build fixes for GStreamer >= 1.3.90

[Adrian Perez]

(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}.

[Ting-Wei Lan]

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?

[Ting-Wei Lan]

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.

[Philippe Normand]

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

[Ting-Wei Lan]

Created attachment 236600 [details]
 Disable memory sampler on non-Linux system (with ChangeLog)

[Carlos Garcia Campos]

Committed r172623: <http://trac.webkit.org/changeset/172623>

[Ting-Wei Lan]

The LDFLAGS problem has not been solved ...

[WebKit Commit Bot]

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

[Philippe Normand]

Please open a new bug or clone this one. We usually deal with one patch per bug.