[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.

From: Rob Landley
Subject: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.
Date: Wed, 17 Feb 2010 12:55:33 -0600
User-agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; )

On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
> >> I've also got a bunch of "sort of working, but not well enough
> >> to run builds natively under" targets on top of that (arm big
> >> endian, sh4, sparc...)
> >
> > What's not well enough on sparc?
>  From http://permalink.gmane.org/gmane.comp.emulators.qemu/63610:
> On Linux, sparc-softmmu can boot Linux (sparc-test) image, but QEMU
> crashes just before command line. On OpenBSD, the same test reaches
> command prompt.

Actually the sparc-test image from http://wiki.qemu.org/download/sparc-
test-0.2.tar.gz boots and gets me a command line just fine, and I've never had 
it die with strange errors that look like mismatched system calls and such.  
(Under ubuntu 8.04, using qemu-git from a week or so back, but this behavior's 
been consistent since I first tried it.0

That image is A) built with an unknown compiler, B) running glibc (not 
uClibc), c) a crippled toy image.  (It's a read-only root filesystem that 
hasn't got a mount point for /proc.  Obviously never mean to actually be used 
for anything but very simple smoke testing.)

But it does imply that qemu is capable of decently running _something_ on 
sparc, so the problems I'm seeing are more likely to be uClibc or toolchain 

Alas the image has no hint how to reproduce it.  Doesn't say what toolchain it 
was built with, what kernel .config was used, and so on.  (The arm one at least 
had /proc/config.gz...)

Well, actually if you "mount -t proc proc lost+found" and then cat 
lost+found/version it says gcc version 2.95.4 20010319 (prerelease).  So it 
was built with a random cvs snapshot of egcs from 2001, configured who knows 
how, and it's running a 2.6.11 kernel from 5 years ago (again with who knows 
what .config).  So my problem could be that I'm using a kernel 22 versions 
newer, or I'm using gcc 4.2 toolchain, or that either is configured differently.

But I'm still guessing uClibc is the most likely culprit...

Latency is more important than throughput. It's that simple. - Linus Torvalds

reply via email to

[Prev in Thread] Current Thread [Next in Thread]