Bug#930935: webkit2gtk: Baseline violation on i386

Alberto Garcia berto at igalia.com
Mon Jun 24 09:29:56 BST 2019

On Mon, Jun 24, 2019 at 12:34:26AM +0300, Adrian Bunk wrote:

> > Building with SSE2 is not a decision made by the Debian
> > maintainers.  Upstream WebKit dropped support for non-SSE2
> > processors and the code assumes that SSE2 is always available:
> > 
> >    https://bugs.webkit.org/show_bug.cgi?id=194853
> "as part of Igalia's work on 32bit support"
> "there were no negative comments"
> Someone should have told upstream at Igalia that non-SSE is
> supported by the Debian i386 port.

This was actually discussed, IIRC the concusion was that this was
a reasonable choice because (a) SSE2 is almost 20 years old, (b)
supporting non-SSE2 CPUs was increasing the maintaince burden for
upstream, and (c) other browsers had already followed the same path
for a few yeas.

> > And so did Firefox:
> > 
> >    https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
> The Debian maintainers have patched both Rust and Firefox to make
> them work on non-SSE i386 despite upstream no longer supporting it.
> There were plenty of bug reports when an SSE-using Firefox recently
> slipped through - and in general based on the numbers of bugs
> submitted non-SSE i386 has more users than half our release
> architectures combined.

Ok, that's interesting information.

Let's try to move forward then. I see three possibilities:

1) Detect SSE2 at runtime. This doesn't seem to be possible at this
   point, or at least not trivially so. Although we still have the
   JavaScriptCoreUseJIT variable, it's unclear whether this would be
   enough. I need to test it.

2) Build with SSE2 completely disabled (using WTF_CPU_UNKNOWN, or
   somethig else, I'm still discussing this with the team). This would
   probably solve the problem but would make all i386 builds much
   slower (in already slow machines) so I suppose many users would
   also complain.

3) Make two builds for i386: one with SSE2 and one without, and have
   two separate packages. Maybe it's too late for this? In any case
   I think this would only affect the libjavascriptcore package, the
   libwebkit2gtk build should be valid for all CPUs. So we'd have
   libjavascriptcoregtk-4.0-18 and libjavascriptcoregtk-4.0-18-sse2 or
   something like that.


More information about the Pkg-webkit-maintainers mailing list