Bug 167411 – [GTK] pixman fails to compile on Raspberry Pi (GCC crash)

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Alex Christensen]

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.

[Alex Christensen]

Created attachment 299682 [details]
file that failed to compile from pixman

[Alex Christensen]

Created attachment 299683 [details]
preprocessed output mentioned in build output

[Michael Catanzaro]

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]

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]

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]

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]

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]

(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]

(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]

(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]

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]

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]

Created attachment 300111 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 300111 [details]
Patch

Clearing flags on attachment: 300111

Committed r211369: <http://trac.webkit.org/changeset/211369>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alex Christensen]

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]

(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.