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

[Rob Landley <rob@landley.net>]

On Wednesday 17 February 2010 14:46:15 Blue Swirl wrote:
> > 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.
>
> The compiler was probably Debian gcc 2.95 package as distributed that
> time, not some random cvs snapshot of egcs.

Ok.  It was the word "prerelease" that made me think snapshot.

I don't suppose you know what the --target tuple that compiler was configured 
with was?  (Should be in the output of "gcc -v"?)

> I can't find the original
> kernel config because I have edited it since, but the attached version
> should not be too far from it. The kernel itself is straight 2.6.11
> plus this patch to fix TCX display. I think the ramdisk contents are
> from the user emulator test set, I didn't build those.

Cool.  The point is, what you've got works under qemu, so the problems I'm 
seeing are less likely to be qemu and more likely to be uClibc or toolchain 
config.  I'll compare your kernel .config with mine.

I'm using serial console, not graphics, so the display patch shouldn't affect 
me directly.

Ben Taylor has offered to try my root filesystem on some real Sparc hardware if 
he can find a Linux for sparc boot cd that works on what he's got.  (The uClibc 
guys say that sparc works for them on real hardware, or did at one point...  
Always funk having 4 or more possible reasons for behavior to be wonky.  
Toolchain, libc, kernel, emulator...  Wheee...)

> Perhaps we should build a new set of test suites for all architectures
> from a single known stack of tools and sources.

That's pretty much exactly what I'm trying to do with my project.  If you look 
in download.sh the URLs for all the source packages I'm downloading are in one 
place, and all the per-target information is in the sources/targets 
directories.  The build scripts themselves are completely target-agnostic.

My release goal for the 1.0 version of my project is "have at least one 
working image for every qemu-system-blah that's actually capable of booting 
Linux".

I've got about half of 'em so far.  I need to tackle the 64-bit ones sooner or 
later.  And then break down and deal with nommu...

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