Bug 167411

Summary: [GTK] pixman fails to compile on Raspberry Pi (GCC crash)
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: WebKit Misc.Assignee: Carlos Alberto Lopez Perez <clopez>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cgarcia, clopez, commit-queue, mcatanzaro, pnormand
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Other   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=147224
Bug Depends on:    
Bug Blocks: 172765    
Attachments:
Description Flags
build output
none
file that failed to compile from pixman
none
preprocessed output mentioned in build output
none
Patch none

Alex Christensen
Reported 2017-01-24 23:44:34 PST
Created attachment 299681 [details] build output I got a Raspberry Pi 3 Model B (ARM64 processor) and installed RASPBIAN JESSIE WITH PIXEL released 2017-01-11 and checked out WebKit r211135 Tools/gtk/install-dependencies failed. "sudo apt-get upgrade" fixed that. NDB. Tools/Scripts/update-webkitgtk-libs failed. I attached the end of the build output, as well as the source file in question and its preprocessor output. It said to file a bug against gcc 4.9. I don't think they would fix gcc 4.9 at this point. I think we should either fix pixman or require a newer version of gcc.
Attachments
build output (81.47 KB, application/octet-stream)
2017-01-24 23:44 PST, Alex Christensen
no flags
file that failed to compile from pixman (96.03 KB, application/octet-stream)
2017-01-24 23:46 PST, Alex Christensen
no flags
preprocessed output mentioned in build output (404.46 KB, application/octet-stream)
2017-01-24 23:46 PST, Alex Christensen
no flags
Patch (1.92 KB, patch)
2017-01-30 08:18 PST, Carlos Alberto Lopez Perez
no flags
Alex Christensen
Comment 1 2017-01-24 23:46:04 PST
Created attachment 299682 [details] file that failed to compile from pixman
Alex Christensen
Comment 2 2017-01-24 23:46:28 PST
Created attachment 299683 [details] preprocessed output mentioned in build output
Michael Catanzaro
Comment 3 2017-01-25 08:49:09 PST
Yeah, it's a GCC crash, and GCC 4.9 is no longer supported upstream. I think we should do nothing. We don't need to bump the GCC requirement when it's working on other architectures.
Alex Christensen
Comment 4 2017-01-25 11:35:58 PST
What do I do locally to get it to use a newer compiler? I'm not familiar with all the webkit/gtk infrastructure.
Michael Catanzaro
Comment 5 2017-01-25 13:08:18 PST
Set the CC and CXX environment variables to point at a newer compiler. Unfortunately GCC 4.9 is the newest GCC available in Jessie, so you'd have to build a newer version yourself, which you don't want to do. I'd first try installing clang and using that instead: CC=/usr/bin/clang CXX=/usr/bin/clang++ update-webkitgtk-libs Failing that, upgrade to Stretch (is there a Stretch-based Raspbian yet?) which has a newer version of GCC.
Michael Catanzaro
Comment 6 2017-01-25 13:12:47 PST
Actually, unless you're planning to run layout tests, you don't need to use the JHBuild environment at all. That's really intended for developers who need to be able to run layout tests to ensure we're all using the same versions of all the dependencies. It's not suitable for actual production use. So probably a better option for you is to just not run update-webkitgtk-libs at all. Clear out WebKitBuild/(build type)/DependenciesGTK and skip straight to running build-webkit, and install system development packages for all the packages that CMake complains is missing. Then you don't have to build pixman at all.
Alex Christensen
Comment 7 2017-01-26 00:11:16 PST
When I run build-webkit --gtk without update-webkitgtk-libs, I have to install several things, but I can't figure out what gtk+-quartz-3.0 is or why it is looking for it on linux. clang worked to build pixman, but it failed to build libffi-3.1: /home/pi/webkit/WebKitBuild/DependenciesGTK/Source/libffi-3.1/src/arm/sysv.S:399:2: error: invalid instruction stmeqia r2, {r0, r1}
Carlos Alberto Lopez Perez
Comment 8 2017-01-26 04:48:43 PST
(In reply to comment #3) > Yeah, it's a GCC crash, and GCC 4.9 is no longer supported upstream. > > I think we should do nothing. We don't need to bump the GCC requirement when > it's working on other architectures. We have an ARM buildbot that has been building this fine for a long time. And I also have built this on a Debian Jessie armhf (ARMv7 32bits) with GCC-4.9 just fine. I think there is something else going there. I will try to trigger a clean build here in the ARMv7 board I have for tests here. Note that the RPI3 has an ARM64 processor, but the kernel and the userland is all 32-bit. You are not using any of the 64-bit capabilities of the CPU unless you build your own Aarch64 kernel and you use an Aarch64 userland. Some people are trying that, check this for more info: https://github.com/raspberrypi/firmware/issues/550 But officially (so far) only 32 bit support is enabled for any RPi.
Michael Catanzaro
Comment 9 2017-01-26 05:27:52 PST
(In reply to comment #7) > When I run build-webkit --gtk without update-webkitgtk-libs, I have to > install several things, but I can't figure out what gtk+-quartz-3.0 is or > why it is looking for it on linux. It's the Mac backend for GTK+ and it's not available on Linux for that reason. You don't want it. It shouldn't be required unless you build with -DENABLE_QUARTZ_TARGET=ON, which you shouldn't do. CMake might print a nonfatal message about it being missing that you should be able to ignore.
Carlos Alberto Lopez Perez
Comment 10 2017-01-26 09:50:41 PST
(In reply to comment #8) > (In reply to comment #3) > > Yeah, it's a GCC crash, and GCC 4.9 is no longer supported upstream. > > > > I think we should do nothing. We don't need to bump the GCC requirement when > > it's working on other architectures. > > We have an ARM buildbot that has been building this fine for a long time. > And I also have built this on a Debian Jessie armhf (ARMv7 32bits) with > GCC-4.9 just fine. > > I think there is something else going there. I will try to trigger a clean > build here in the ARMv7 board I have for tests here. I have just built it fine. I can't reproduce that error. This is my system: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.5 (jessie) Release: 8.5 Codename: jessie $ uname -a Linux wandboard 4.0.3-armv7-x2 #1 SMP Thu May 14 14:30:32 CST 2015 armv7l GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Do you have something different? I may retry with a rpi3 and that image <RASPBIAN JESSIE WITH PIXEL released 2017-01-11> to see if i can reproduce it there.
Carlos Alberto Lopez Perez
Comment 11 2017-01-26 10:44:32 PST
It seems this is a known issue. The EFL guys have work-arounded it by passing --disable-arm-iwmmxt in the configure flags for pixman. See bug 147224 I still don't know why I can't reproduce it on my environment.
Carlos Alberto Lopez Perez
Comment 12 2017-01-30 08:01:50 PST
This is the issue explained: * pixman has an optional fastpath for iwMMXt ("Intel Wireless MMX Technology"), which are an extension of the ARM instruction set found in some Intel's and Marvell's XScale microprocessors. * On the configure step, pixman tests the compiler to see if has support for iwMMXt. On the raspberrypi with pixel this test passes, but on a standard Debian ARMv7 it doesn't. The explanation is that for iwMMXt support the compiler has to use ARM traditional instruction set. And Debian defaults to use Thumb2 instruction set, meanwhile Pixel/Raspbian defaults to ARM traditional. So in standard Debian this test doesn't passes and the support for iwMMXt is disabled in the configure step, avoiding that way the compiler bug on the compile step. On the RPI with Pixel the test passes and support for iwMMXt is enabled, causing the failure on the build step. Given that: * Boards with this iwMMXt instructions are rare (I never saw one and its the first time I hear about this iwMMXt thing) * We are already disabling MMX for another build issue with Clang (And MMX instructions are practically on every recent x86 chip). See bug 151441 * The performance implications of disabling iwMMXt don't look like a game changer: https://people.freedesktop.org/~mattst88/iwmmxt-benchmarks/cairo-perf-trace-summary * This will be a no-op on any standard Debian (and probably also on other distros like Ubuntu or Fedora) system. As Debian defaults to use Thumb2 on ARMv7. * The goal of the JHBuild is not to build the libraries for production, but for allowing the developers to have consistent layout test results. So I think its ok to disable any optimization on this libraries when it helps the goal of allowing the build to succeed on any developer machine. So, I think we should disable this like it has been done for the EFL port. Patch coming
Carlos Alberto Lopez Perez
Comment 13 2017-01-30 08:18:59 PST
WebKit Commit Bot
Comment 14 2017-01-30 09:10:29 PST
Comment on attachment 300111 [details] Patch Clearing flags on attachment: 300111 Committed r211369: <http://trac.webkit.org/changeset/211369>
WebKit Commit Bot
Comment 15 2017-01-30 09:10:33 PST
All reviewed patches have been landed. Closing bug.
Alex Christensen
Comment 16 2017-02-05 00:58:36 PST
I had forgotten to install libicu-dev and disable WebRTC and MediaStream in Tools/Scripts/webkitperl/FeatureList.pm because I don't have openwebrtc on my system, but it has started compiling. I had to run ninja -j2 because there isn't enough memory to reliably run more than two gcc instances in the 1GB of memory.
Carlos Alberto Lopez Perez
Comment 17 2017-02-05 16:26:16 PST
(In reply to comment #16) > I had forgotten to install libicu-dev and disable WebRTC and MediaStream in > Tools/Scripts/webkitperl/FeatureList.pm because I don't have openwebrtc on > my system, but it has started compiling. I had to run ninja -j2 because > there isn't enough memory to reliably run more than two gcc instances in the > 1GB of memory. The RPi3 has only 1GB of RAM that is shared with the GPU. I'm not sure if you will be able to build WebKit on it. The linking step requires quite a few RAM. I would suggest a board with at least 2GB of RAM, or cross-building on a powerful x86_64 machine. Tools like buildroot or yocto/openembedded allow one to easily cross-build for a range of boards/architectures.
Note You need to log in before you can comment on or make changes to this bug.