Re: [Qemu-devel] qemu + chroot with non native image

[Veli Mankinen]

Hi,

Project named Scratchbox aims to solve these cross-compilation and
cross-configuration problems with similar approach as you described
here. Qemu support has just been added to the latest pre release. Before
that we used real devices and rsh kind a program that was executed using
binfmt_misc (this is ofcourse still possible). Scratchbox also has other
features that help cross-compilation.

The next pre release (0.9.8-pre4) that will be released next week, will
most likely come with ppc support also. Now sb has arm and x86 support.

http://scratchbox.org/

        - Veli



On Sat, Feb 28, 2004 at 11:36:14AM +1000, James Boddington wrote:
> Have been having a bit of a play.
> 
> I used binfmt_misc to register qemu-ppc as the interpreter for ppc 
> binaries. This allows me to run ppc binaries on my athlon with out having 
> to specify qemu-ppc everytime.
> 
> This seems to be usefull when cross compiling a few packages that create an 
> intermediate step that is built for the target instead of the build host. 
> The binary fails to run and the build process stops. Using binfmt_misc + 
> qemu-XXX allows this step to complete and the build can finish. 
> 
> For example texinfo-4.4 builds a binary part way though the build process 
> and tries to use that binary to process a few files. This binary has been 
> cross compiled and fails to run. Using the above idea I can cross compile 
> this package. 
> 
> Python 2.2.x is another offender. A python binary is built that is then 
> used to build python proper. The 1st python won't run because it is for 
> the wrong arch. Using binfmt_misc + qemu-ppc the build was going fine 
> until qemu-ppc seemed to go into a loop. Qemu-ppc sat just under 100% cpu 
> doing nothing obvious until I killed the process.
> 
> Another use I have found for this is being able to chroot into a non native 
> filesystem. I cross compile my sparc images (x86 -> sparc) because it is a 
> lot quicker. So being able to chroot into the image is of interest to me.
> 
> For this exercise I built a toolchain for ppc-unknown-linux-gnu and cross 
> compiled a small image. Placed a static qemu-ppc in opt/bin in the image. 
> I have not tried to see if it can self host yet.
> 
> MAKEDEV bzip2 egg fileutils gcc gzip linux-headers ncurses sed tar wget 
> bash diffutils file findutils glibc kbd make patch sh-utils texinfo zlib 
> binutils ed filesystem gawk grep libtool mktemp procps shadow textutils
> 
> /var/tmp/ppc-image, Sat Feb 28 11:19:51
> (address@hidden) uname -a
> Linux fred.bedrock 2.4.24 #3 Fri Feb 27 21:41:37 EST 2004 i686 unknown 
> unknown GNU/Linux
> 
> /var/tmp/ppc-image, Sat Feb 28 11:19:54
> (address@hidden) chroot . /opt/bin/qemu-ppc /bin/bash
> 
> /, Sat Feb 28 01:20:03
> (address@hidden) uname -a
> Linux fred.bedrock 2.4.24 #3 Fri Feb 27 21:41:37 EST 2004 i686 unknown 
> unknown GNU/Linux
> 
> /, Sat Feb 28 01:20:08
> (address@hidden) file /bin/bash
> /bin/bash: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
> (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), 
> stripped
> 
> /, Sat Feb 28 01:20:15
> (address@hidden) file /usr/bin/gcc
> /usr/bin/gcc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
> (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), 
> stripped
> 
> /, Sat Feb 28 01:20:23
> (address@hidden) /usr/bin/gcc -v
> Reading specs from /usr/lib/gcc-lib/ppc-unknown-linux-gnu/3.3.3/specs
> Configured with: ./configure --prefix=/usr --build=i686-pc-linux-gnu 
> --host=ppc-unknown-linux-gnu --target=ppc-unknown-linux-gnu --disable-nls 
> --enable-shared --enable-threads=posix --enable-languages=c,c++
> Thread model: posix
> gcc version 3.3.3
> 
> -- 
> 
>    James 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/qemu-devel