Userspace emulation won't be meaningfully faster. There is no real alternative to getting a faster ARM machine.

On the cheaper end, an decently specced 8 core (4+4) can be had for under $200. Samsung Chromebook 2 is more expensive but I find it more convenient.

On the higher end, a Gigabyte MP30-AR0/AR1 is a monster and it takes standard DDR3 DIMMs, but it is quite expensive. I got one specifically for compiling packages. If you decide to go down that route, if you rebuild the kernel with the more reasonable 4KB page size, you can run a 32-bit chroot or docker container on an aarch64 host (that is the setup I use). I filled mine up with 128GB of RAM, so even bloadware like LibreOffice and web browsers can compile entirely on tmpfs, which helps significantly.


On Fri, Dec 23, 2016 at 6:18 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
On 23 December 2016 at 02:35, mo.ucina <mo.ucina@gmail.com> wrote:
> Hello Guys,
>
> I have been doing centos package compiling on arm hardware for a while now ,
> and it has been going OK . One drawback is that some bigger packages would
> run for 10hrs to compile . I would like to speed up that process , and
> compile on a much more powerful machine . I tried cross-compiling but ended
> up with issues when the arm package got contaminated with i386 libraries no
> matter what I tired .
>
> I also tried qemu VM running on my core2duo 4 core desktop machine . This
> worked OK as packages were perfect , but it was slower to compile than using
> arm hardware . Same package that took 10 hrs on arm hw , compiled for 3 and
> a half days on the desktop .
>
> My question is if I used a chroot approach to run the emulation will this be
> quicker than a qemu VM . If so can anyone please share their instructions on
> how to configure a chroot to run a centos 7 arm image on a x86 desktop.

I am probably misunderstanding what you are wanting.. but my initial
thought is that you can't.

The ARM uses a completely different computer architecture to x86_64.
This means that you can't just chroot into an arm environment because
the underlying processor (x86_64) isn't changing. It is still going to
try and interpret machine code 32 to be one thing even if on an ARM
that meant something completely different. [Also the fact that even if
machine code 32 was the same the ARM has different number of registers
and other internals than an x86]

You are running into the same problems we have had with ARM
development over the last N years. The only solutions are

a) Patience with the slow hardware you have.
b) Get more hardware but still have patience
c) Get large scale server hardware and have patience.

The emulation problem you are running into is pretty much standard
because of the translation of a RISC architecture on a CISC
architecture. The most off the shelf ARM systems are equivalent to a
P400 MHZ from the early 2000's in some ways but also faster in others.
[Trying to use a P400 to compile say texlive is a multi day event
while on an arm system it might be only 10-20 hours.]  You have a
slightly better emulation result if you have an 64 bit arm 'emulate' a
32 bit arm but that is hardware dependent and still requires patience.



>
> Best Regards
>
> Milorad
>
> _______________________________________________
> Arm-dev mailing list
> Arm-dev@centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev



--
Stephen J Smoogen.
_______________________________________________
Arm-dev mailing list
Arm-dev@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev