Bug 137147 – [GTK] Bump up and patch dependencies to allow building for aarch64

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Akos Kiss]

Some of the GTK dependencies built with jhbuild don't configure (or configure incorrectly) for aarch64. For WebKitGTK to build on aarch64, these libraries need to be bumped up/patched. 

This is very similar to the situation we had on EFL earlier: https://bugs.webkit.org/show_bug.cgi?id=135885 .

[Akos Kiss]

Created attachment 238710 [details]
Proposed patch.

[Martin Robinson]

Have you verified that this doesn't change layout test results?

[Akos Kiss]

Created attachment 239021 [details]
Updated patch (v2)

In the last some days I've been struggling to be able to answer a self-confident yes to the question. But. At least on my box, no consecutive runs of run-webkit-tests produce the same results, not even with the unpatched version of the code base. There are unexpected crashes reported, some number between 20 and 50, but almost never on the same tests. The situation is very similar with the patched version of the code. However, by manually running the tests reported crashing in MiniBrowser, I've never experienced any crashes.

Thus, I've been scratching my head a bit and came up with a reduced version of the original patch, which does not tackle xserver. First of all, because I found that the patch I wanted to introduce in the jhbuild.modules for xserver is bugous, and also because it seems to me that the dependency of xserver on x11proto-present-dev prevents the GTK EWS to test the patch. Hopefully, the EWS will turn out to be more stable than my box and will signal green now. 

If so, and in case of a positive review, the xserver bump-up can be done separately afterwards.

[Martin Robinson]

(In reply to comment #3)
> Created an attachment (id=239021) [details]
> Updated patch (v2)
> 
> In the last some days I've been struggling to be able to answer a self-confident yes to the question. But. At least on my box, no consecutive runs of run-webkit-tests produce the same results, not even with the unpatched version of the code base. There are unexpected crashes reported, some number between 20 and 50, but almost never on the same tests. The situation is very similar with the patched version of the code. However, by manually running the tests reported crashing in MiniBrowser, I've never experienced any crashes.


If the tests aren't working for you, why do you want to update the JHBuild dependencies? The JHBuild is in available to ensure consistent test runs across systems. If you simply need a convenient way to install dependencies, take a look at jhbuild-wayland.modules for how we've done that in the past.

[Akos Kiss]

(In reply to comment #4)
> If the tests aren't working for you, why do you want to update the JHBuild dependencies? The JHBuild is in available to ensure consistent test runs across systems. If you simply need a convenient way to install dependencies, take a look at jhbuild-wayland.modules for how we've done that in the past.

My goal was/is to get everything work on ARM64/Linux just as it is working elsewhere, like on x86/Linux or x86-64/Linux:
Tools/{gtk,efl}/install-dependencies
Tools/Scripts/update-webkit{gtk,efl}-libs
Tools/Scripts/build-{jsc,webkit} --{gtk,efl}
Tools/Scripts/run-{javascriptcore,webkit}-tests --{gtk,efl}

My first planned step was to get everything build correctly on ARM64 so that it does not break anything elsewhere.

It seems that I've left out from my previous comment that the unstable behaviour was not experienced on an ARM64 device but on an x86-64/Ubuntu 14.04 machine. (Which must be some problem on my side, of course, and I'll try to find and fix it.) That's why I was looking for the result of the EWS, which I expected to be perfectly configured. (And now it seems that the patch passed the test.)

[Akos Kiss]

Created attachment 239212 [details]
Updated patch (v3)

Thanks for not letting me get sloppy!

It turned out that my x86-64/Ubuntu 14.04 desktop machine was trying too heavily to parallelize the execution of the layout tests, which resulted in random crashes. After specifying --child-processes=3 for run-webkit-tests, the results became stable, both before and after applying the patch.

After bumping-up the libs, http/tests/media/video-redirect.html became crashing. By tracing back the error, it turned out that a bug has been hiding in gst-plugins-base in the .mov demuxing. (This is interesting, since neither gstreamer nor gst-plugins-base has been touched during the bump-up. This bug has been there for a while, only did not reveal itself, hitherto.) Fortunately, a one-line fix already exists and got accepted in gstreamer upstream.

Now, this version of the patch introduces no regressions on x86-64 anymore, and builds on Aarch64.

[Martin Robinson]

Comment on attachment 239212 [details]
Updated patch (v3)

Okay. This is a little annoying because it invalidates a lot of our pixel results, but those are pretty out-of-date and we need to regenerate them to support hidpi anyway.

[WebKit Commit Bot]

Comment on attachment 239212 [details]
Updated patch (v3)

Clearing flags on attachment: 239212

Committed r174274: <http://trac.webkit.org/changeset/174274>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.