building busybox with a different uclibc to the toolchain version

[Stuart Hughes]

On Wed, 2006-11-01 at 00:49 +0100, Denis Vlasenko wrote:
> On Tuesday 31 October 2006 17:45, Stuart Hughes wrote:
> > I'm not really sure if this is a uClibc/gcc or busybox question, but
> > here goes:
> > 
> > I'm trying to build a powerpc target image using an older uClibc (0.27)
> > than the one in my cross compiler (0.28).  The version of busybox I'm
> > building is 1.1.3.
> > 
> > The build works okay, but when I try to boot init just hangs.
> > I tried building busybox statically and when this boots it dies:
> > 
> > "init has generated signal 11 but has no handler for it"
> > 
> > Anyone have any ideas what is wrong?
> 
> 11 is SIGSEGV. Is it specific to init? (IOW: can you boot with
> init=/bin/sh?)
> --
> vda
> 

No, this happens if I pass init=/bin/sh or any other applet.

What I'm trying to do is to build an older uClibc-0.27 based rootfs with
a pre-built cross compiler that includes uClibc-0.28.  What I'm
wondering is whether something incompatible can "leak" from the
toolchain and cause this problem.  I turned on debugging in uClibc and
saw this:

VFS: Mounted root (nfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 96k initê.ELF...0x30000000
.ELF...0x30016aac
.ELF....ELF....ELF....ELF...Done relocating library loader, so we can
now
        use globals and make function calls!
Cool, we managed to make a function call.
malloc: mmapping more memory
Lib Loader:     (0x0) /lib/ld-uClibc.so.0
calling mprotect on the application program
Loading:        (0x30017000) /lib/libcrypt.so.0
Loading:        (0x3003d000) /lib/libgcc_s.so.1
Loading:        (0x3005a000) /lib/libc.so.0
Loading:        (0x3005a000) /lib/libc.so.0
Loading:        (0x3005a000) /lib/libc.so.0
Beginning relocation fixups
transfering control to application
init has generated signal 11 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!

Does that look familiar, or can you suggest anything else to try out.

Regards, Stuart