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! ) Best Regards On Mon, Dec 1, 2014 at 8:48 PM, Siarhei Siamashka < [email protected]> wrote: > On Mon, 1 Dec 2014 10:12:05 +0000 > Andrea Giammarchi <[email protected]> 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/ > > -- > Best regards, > Siarhei Siamashka >
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
