[webkit-dev] Hosting precompiled `jsc` binaries for Linux

[Adrian Perez de Castro]

Hello, everybody.

On Tue, 12 Dec 2017 01:29:42 +0100, Carlos Alberto Lopez Perez <clopez at igalia.com> wrote:
> On 08/12/17 18:07, Lucas Forschler wrote:
> > If the GTK team wanted to support making these accessible,
> > they have everything they need. They could either choose to open up
> > their firewall so external folks could access them. Or, they could put
> > full archives on build.webkit.org <http://build.webkit.org> (which would
> > be transferred to s3/webkit build archives).
> > 
> > Maybe someone over there would be willing to take on this work if it is
> > in their budget. (Both time and bandwidth)
> >
> 
> 
> Hi Lucas, Mathias, et all.
> 
> This is bit more complex that it seems. I will try to explain.
> 
> The built products the WebKitGTK+ bots currently generate are being
> uploaded to a local server that was only reachable from the Igalia
> intranet [1]. I have just changed that, and the build products should
> be now accesible for everybody at:
> 
> http://webkitgtk-release.igalia.com/built-products/
> (also available via https if you prefer)
> 
> Keep in mind that currently we delete the built products after 10 hours,
> so don't expect to find there more than the very last few builds.
> That is just enough time for the test bots to download and test them.
> 
> We are happy on configuring a less aggressive purging of this files to
> keep them available for much longer. We can as well make this resource
> available from a more official domain (like webkit.org or webkitgtk.org)
>  
> But before doing that I will like to know if this files will be useful
> for you in the end (or not). See below.
> 
> If you download one of those build products and try to run it on your dev
> machine you are likely to have some problems with the shared libraries.
> 
> The main issue is that this binaries are linked against a bunch of libraries
> that we build in a internal JHBuild, and will likely differ from the ones
> shipped by your distro.
> 
> To test it, you can download one of this zip files and try running:
> 
> for JSC:
> LD_LIBRARY_PATH=$(pwd)/lib bin/jsc
> 
> for WebKit:
> LD_LIBRARY_PATH=$(pwd)/lib WEBKIT_EXEC_PATH=$(pwd)/bin WEBKIT_INJECTED_BUNDLE_PATH=$(pwd)/lib bin/MiniBrowser
> 
> 
> Perhaps the JSC binary works because it has few dependencies (libicu and
> glib mainly), but I doubt the WebKit one will do. Your mileage may vary.

JSC binaries should indeed be easy to move from one system to another.
 
The public API in GLib has been stable for a long time, so I would not
expect it to be an issue when linking dynamically. In the case of ICU, the
public API changes now and then, and with different GNU/Linux distros
providing different versions I would expect it to be a problem.

As for WebKitGTK+ (MiniBrowsert, libwebkit2gtk, etc.) I would expect moving
the built binaries to other systems quite problematic. The only really safe
way I see is including *all* the dependency libraries from the JHBuild in the
downloadable archives.
 
> And this will be only for the 64-bit builds. Our current 32-bit buildbots
> are test&build ones, which means they don't currently generate and upload
> a built-product. They just test it after building it and then discard it.
> There maybe the possibility of adding an extra step to add the upload in
> case you find this built products useful.
> 
> Trying to look forward for a more elegant solution I tried to generate a
> static build of JSC with the JSCOnly port, but I failed when trying to
> link statically with libicu. I have reported that on the bug below:
> https://bugs.webkit.org/show_bug.cgi?id=180678

Statically linking the “jsc” binary would work well here, I think. Like I
mentioned above, probably dynamically linking GLib would be fine, and only ICU
needs to be statically linked for good. Then again, once we start linking
statically... what's 1 MiB more in the text section? :-)

> Let me know your thoughts.
> 
> Regards
> -------
> 
> [1]
> We do that because the server that generates the built product as well as the
> others that donwload it for testing are on the same LAN. So it makes little
> sense for us to daily upload and download gigabytes worth of data to Internet, 
> when we can just serve the resources locally.
> 
> Doing that will make every build slower because then the build-only bot
> will have to wait for an upload to Internet rather than to a local server,
> as well the test-only bot will have to wait for a download from Internet. 
> Our bandwith to Internet is much less than a gigabit LAN.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20171212/54d3b368/attachment.bin>