[Webkit-unassigned] [Bug 217079] REGRESSION(r259582): Build fails on aarch64 Linux with WebKit 2.30.1 on LLIntOffsetsExtractor.cpp.o

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=217079

--- Comment #14 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Mike, I've been talking with Mark about this. This build failure only occurs when cloop and JIT are both enabled. This is not a configuration that we *intentionally* use on Linux (although Apple uses it). Problem is I changed WebKitFeatures.cmake a while back to do the right thing on all architectures, so we no longer have to pass -DENABLE_JIT=OFF -DUSE_SYSTEM_MALLOC=ON. Except it really only does the right thing on all architectures *except* aarch64, where it's impossible to make the right choice without knowing system page size (which could be different on the builder than on the target system). So enterprise distros that support 64k pages still need to set these flags manually, but only for aarch64. Now here is my mistake: I used to have WebKitFeatures.cmake set up such that -DENABLE_JIT=OFF would set -DENABLE_C_LOOP=ON. And I assumed that was still the case, but it no longer is, because that code was no longer needed anymore now that it does the right thing for "all" architectures (oops). So you're ending up with cloop disabled by mistake, and that is why LinkBuffer.cpp is being compiled. I have the identical mistake in RHEL's build system too.

So there are two problems: (a) you should build with -DENABLE_C_LOOP=ON. (b) this  bug really should be fixed as Mark suggests, but it should only affect Apple ports because only Apple ports should be building this file with JIT disabled.

P.S. There is no amazing reason to always enable cloop when JIT is disabled. Upstream WebKit has three options: cloop, asm llint, and JIT. We just simplify it down to two for Linux so there is one fewer case to think about. Hence, it's not wrong or horrible to ship with both cloop and JIT disabled, just not what I had intended.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200930/722fdac7/attachment-0001.htm>