On Thu, May 24, 2012 at 11:06:30AM -0400, wrote: > On Thu, May 24, 2012 at 08:59:57AM +0100, Tixy wrote: > > Not that horrible. I just did a kernel build on my laptop in an ARM > > chroot and it took 19m43s, doing it as a cross-build took 1m14s. I > > haven't got my Pandaboard setup to do a comparison, but I > > suspect it wouldn't be much faster than my emulated ARM run. > > Well complete system emulation is very very slow, which is what I have > used in qemu. I had forgotten it did the instruction emulation only > as well. > > > I'm not talking about using QEMU as a system emulator, just an > > instruction set emulator. So ARM processes are running and scheduled as > > native X86 PC processes, just using QEMU to interpret the instructions > > in ARM ELF files. (There may be other magic going on, all I really know > > about QEMU is how to make use of it following cut'n'paste instruction > > from the web). > > That would probably be faster. I haven't tried that method. > > > In the kernel building example I mentioned I was using "make -j8" and > > that went a _lot_ faster than -j1; I didn't wait to get final timings > > for a single threaded build. > > OK, using the instruction emulation, then you could do that. That's a > pretty good idea. I will have to play with that some more some time.
How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120524162253.ga2...@csclub.uwaterloo.ca
