[arch-general] building x86_64 packages under qemu?
Is there any reason why building x86_64 packages under qemu-system-x86_64 would be a bad idea? It is a little slow, but it is usable. Plus, qemu has a curses interface. -- Chris
Am Montag 11 Januar 2010 schrieb Chris Brannon:
Is there any reason why building x86_64 packages under qemu-system-x86_64 would be a bad idea? It is a little slow, but it is usable. Plus, qemu has a curses interface.
-- Chris
why not using a chroot for this? ok this only works if you have a 64bit machine running. -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski
Am Montag 11 Januar 2010 schrieb Chris Brannon:
Is there any reason why building x86_64 packages under qemu-system-x86_64 would be a bad idea? It is a little slow, but it is usable. Plus, qemu has a curses interface.
why not using a chroot for this? ok this only works if you have a 64bit machine running.
Right, I don't have 64-bit hardware. That's the only reason I'm interested in this approach. -- Chris
Am 11.01.2010 17:48, schrieb Chris Brannon:
Is there any reason why building x86_64 packages under qemu-system-x86_64 would be a bad idea? It is a little slow, but it is usable. Plus, qemu has a curses interface.
It is not a little slow, but painfully slow (remember: the compiler runs in an emulated environment, where each CPU instruction issued by the compiler is translated into a CPU instruction that the host CPU understands, and the result is somehow translated back). You could build a package that consists of a handfull of source files, but any bigger project will be impossible. If you really want to do this, it might be better (but surely not easier, this is rather Voodoo) to port makepkg to using a cross-compiler toolchain.
Thomas Bächler
It is not a little slow, but painfully slow (remember: the compiler runs in an emulated environment, where each CPU instruction issued by the compiler is translated into a CPU instruction that the host CPU understands, and the result is somehow translated back).
Yes, I've noticed that the ./configure step is especially painful, because of all of the little test programs that it compiles. Running ./configure for a small project took the good part of half an hour.
If you really want to do this, it might be better (but surely not easier, this is rather Voodoo) to port makepkg to using a cross-compiler toolchain.
Sounds risky, as well. At some point, it'll become worthwhile to simply upgrade my platform. -- Chris
At Dienstag, 12. Januar 2010 12:27 Chris Brannon wrote:
Yes, I've noticed that the ./configure step is especially painful, because of all of the little test programs that it compiles. Running ./configure for a small project took the good part of half an hour.
Do you use virtio in your vm? http://www.linux-kvm.org/page/Boot_from_virtio_block_device If you use disklabels in your vm (menu.lst, fstab) than you have only to change your start script. This helps a lot but sure it can't replace fast hardware. See you, Attila
On Tue, Jan 12, 2010 at 21:31, Attila
At Dienstag, 12. Januar 2010 12:27 Chris Brannon wrote:
Yes, I've noticed that the ./configure step is especially painful, because of all of the little test programs that it compiles. Running ./configure for a small project took the good part of half an hour.
Do you use virtio in your vm?
he is not using kvm (and kvm will not make a virtual 64bit cpu on a 32bit guest) -- damjan
At Mittwoch, 13. Januar 2010 01:43 Damjan Georgievski wrote:
he is not using kvm (and kvm will not make a virtual 64bit cpu on a 32bit guest)
Thanks for this hint. I thought he is using kvm because the binary has the same name. This was a mistake of mine. See you, Attila
participants (6)
-
Attila
-
Chris Brannon
-
Chris Brannon
-
Damjan Georgievski
-
Thomas Bächler
-
Tobias Powalowski