[Pixman] Unable to build master on Raspberry PI

[Siarhei Siamashka]

On Tue, 2 Dec 2014 07:53:38 +0200
Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:

> On Mon, 1 Dec 2014 23:46:43 +0000
> Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> 
> > On Mon, Dec 1, 2014 at 8:48 PM, Siarhei Siamashka <
> > siarhei.siamashka at gmail.com> wrote:
> > 
> > > On Mon, 1 Dec 2014 10:12:05 +0000
> > > Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> > >
> > > > Hello there,
> > > >   I wonder if anyone else ever tried to build directly on the R-Pi
> > > without
> > > > reaching the (in)famous "Max. number of generated reload insns per insn
> > > is
> > > > achieved (90)" point.
> > > >
> > > > I can build just fine with same dependencies and OS ( Arch Linux )
> > > > everywhere else but in the ARM v6 hf I keep having troubles.
> > > >
> > > > I know this error is usually a GCC one and I am not sure I should even
> > > > bother here, but from mesa to cairo, including varius xorg, pixman is the
> > > > only one that never manages to complete its build.
> > > >
> > > > Will try eventually a stable branch instead of latest from master and let
> > > > you know.
> > > >
> > > > Thanks for any outcome ( if any, thanks for pixman otherwise anyway )
> > >
> > > I have just tested building the current pixman master branch on an
> > > ARM board with GCC 4.8.3. It compiled fine and passed the 'make check'
> > > tests. The native and crosscompiled builds of pixman should generally
> > > work fine on ARM.
> > >
> > > First of all, you can probably try to ensure that the compiler is not
> > > running out of memory and maybe enable a large swap. Raspberry Pi
> > > does not have much RAM.
> > >
> > > Also pixman uses deep inlining and somewhat complicated code constructs
> > > in some places. And it has triggered a number of compiler bugs in the
> > > past. Especially with the unstable/experimental dot-zero versions of
> > > compilers. In such cases, we typically report problems to GCC/Clang
> > > developers and the problems tend to be addressed relatively fast.
> > > Tools like C-Reduce can be used for finding a smaller testcase when
> > > debugging internal compiler error problems:
> > >     http://embed.cs.utah.edu/creduce/
> >
> > Thanks Siarhei,
> >   I have 4GB /swap that made me build even QtWebEngine ( blink + v8 ...
> > basically 2/3rd of Chromium ) so I'd say that both linker ( ld.gold by
> > default ) and swap should be fine but I actually don't have right now exact
> > version of the GCC used in Arch Linux but usually it's the latest one.
> > 
> > I also can build pixman in ARM v7 hf boards but I could not manage yet in
> > the R-Pi model B
> > 
> > I will try to see if I can use C-Reduce so thanks for your hint but if you
> > have anything else in mind that could cause pixman only to fail please
> > share ( at some point I thought it was about NEON which is not supported in
> > the PI ... I haven't disabled that during build time, might try doing that
> > and fingers crossed! )
> 
> BTW, if your Raspberry Pi happens to be overclocked, then it might be a
> potential source of reliability problems too.
> 
> Running "gcc -v" should provide information about the GCC version and
> its configuration.
> 
> NEON code is unlikely to cause problems because most of it is
> implemented in assembly language, so the C compiler is not used
> for it and can't fail.

Actually I have managed to reproduce something similar with the
following toolchain generated by the gentoo crossdev tool:

$ arm-test-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-test-linux-gnueabi/gcc-bin/4.9.1/arm-test-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-test-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-test-linux-gnueabi
Configured
with: /var/tmp/portage/cross-arm-test-linux-gnueabi/gcc-4.9.1/work/gcc-4.9.1/configure
--host=x86_64-pc-linux-gnu --target=arm-test-linux-gnueabi
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/arm-test-linux-gnueabi/gcc-bin/4.9.1
--includedir=/usr/lib/gcc/arm-test-linux-gnueabi/4.9.1/include
--datadir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1
--mandir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1/man
--infodir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1/info
--with-gxx-include-dir=/usr/lib/gcc/arm-test-linux-gnueabi/4.9.1/include/g++-v4
--with-python-dir=/share/gcc-data/arm-test-linux-gnueabi/4.9.1/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.9.1 p1.0, pie-0.6.0'
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/arm-test-linux-gnueabi --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-altivec --disable-fixed-point --disable-libgcj
--disable-libgomp --disable-libmudflap --disable-libssp
--disable-libquadmath --enable-lto --without-cloog
--enable-libsanitizer --with-cpu=cortex-a8 --with-float=hard Thread
model: posix gcc version 4.9.1 (Gentoo 4.9.1 p1.0, pie-0.6.0) 


It fails to compile the pixman mmx (arm-iwmmxt) code:

  CC       libpixman_iwmmxt_la-pixman-mmx.lo
pixman-mmx.c: In function 'mmx_fetch_x8r8g8b8':
pixman-mmx.c:3911:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
Makefile:1111: recipe for target 'libpixman_iwmmxt_la-pixman-mmx.lo' failed


If that's what you get, then the workaround is simple. You can
run the configure script with "--disable-arm-iwmmxt" option.

-- 
Best regards,
Siarhei Siamashka