Jump to content


Firefox (xpcshell) being a pain

xpcshell compile fail

  • Please log in to reply
16 replies to this topic

#16 Karl L.

Karl L.


  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 04 March 2013 - 01:32

Now I understand how its possible to run an ARM chroot on AMD64, but I submit that using qemu is cheating! You're technically running a chroot, but qemu is translating the ARM instructions into your processor's native instructions, hence "cheating". That said, it sounds a lot like the method implemented by qemubuilder (which builds packages for PowerPC on my 2.4 GHz Core2Quad much faster than I can build them natively on my 1.5 GHz G4 - despite the fact that qemu is wasting cycles doing translation on the former but not the latter). In my experience the packages built with qemubuilder work properly when installed on their target architecture.

#17 OP n_K


    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 04 March 2013 - 08:55

There's 2 ways to build packages for different systems, one is using qemu and might work (just had a quick google and there's a bunch of people using qemu to compile MAME and whatnot for the raspberry pi, I was building kernels around 2 months after the RPi got released) but as qemu is an emulator, it's not guaranteed to ever work 100% like for example SNES emulators... The only accurate SNES emulator is bsnes!
The other method is doing a cross-compile using the GCC (or other compiler) tools compiled for your architecture but with all the code translation for the target system and not your processor (binaries are guaranteed to work this way as the compiler/assembler/linker is the same as if you were running it natively on the target system) and you can also do everything GCC can do such as distcc builds for faster compilation.

In terms of qemu you've also got the problem of the actual CPU architecture, e.g. the raspberry pi is an armv6h, h standing for hardware floating point, and from what I remember qemu emulates a generic ARM CPU not a specific type so if for exampleit emulated armv7, you'd be generating instructions that the armv6 isn't able to run. This isn't too much of a problem for other CPUs such as powerpcs or x86 CPUs for example, e.g. x86's got extra instruction sets added such as SSE1, SSE2, AES-on-chip, Intel TXT, etc. but these are not part of the core x86 instruction set (i686) and require special -mtune parameters when these features want to be used using GCC and other compilers.