[Clfs-support] boot process hangs on init.

[binghoo dang]

Just compile a  simpile hello world program and try again!

#include <stdio.h>
int main(void)
{
      printf("Hello world!\n");
      return 0;
}
Compile:
> arm-linux-gcc -c hello.c -o hello

add this "init=/hello" use your bootloader and then see what happens.

Maybe it is wrong with your init!

2008/3/22, Andy Kennedy <akennedy at techmoninc.com>:
>
> Joe Ciccone wrote:
> > Joe Ciccone wrote:
> >
> >> Andy Kennedy wrote:
> >>
> >>
> >>> Why can I not get a dynamically linked program to run under the
> >>> cross-compile system?
> >>>
> >>>
> >>>
> >> You can run ARM code on a X86.
> >>
> >>
> >>
> >>
> > Wow, sorry. You _can't_ run ARM code on a x86.
> > _______________________________________________
> > Clfs-support mailing list
> > Clfs-support at lists.cross-lfs.org
> > http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
> >
> >
> >
>
> Which is why I was attempting to run the dynamically linked program
> under a NFS mounted system -- Problem is, however, that I'm getting a
> seg fault when I do it this way, however, when I mount the sucker via
> USB device OR via MTD (on jffs2) I cannot get ANYTHING out of it --
> which is why I'm trying to debug this system in a controlled environment
> (ON THE ARM).
>
> When statically linking a program, if I'm not mistaken, the linker
> actually chooses the libs from within the cross-tool directory, also,
> these files are ALL .a files.  I have no problem with the tool-chain
> compiler, but there is something way out of whack with the cross-built
> native library (which, shouldn't this be about the same thing as the
> cross-built cross-compiler library with it only being homed
> differently?).  I cannot even get the system to dump a core file for me
> (the system that I'm on has my custom kernel in it already -- the
> default left out most of the stuff I needed).  Something is really
> really screwy and I have not found ANYTHING about it.
>
> When init starts (with the system either on USB stick or via the MTD)
> the system doesn't crap out and give a kernel panic (the original e-mail
> depicted this by showing that I could plug in the USB stick AFTER init
> takes control) which means that init is still running, but just hung up
> somehow.  WHY?  I've been fussing around this issue for about three
> weeks.  I cannot find ANY information about it out on the web. . . I
> cannot find out, even, if it is possible to build a GlibC 2.6.1 base on
> the ARM -- everything I found said that the best thing to use for ARM
> was GlibC 2.3.6 or uClibC.  As for the latter, I couldn't get readdir()
> and opendir() to work when statically or dynamically linking to it, so I
> cannot use that without doing some major rewrites of my code.
>
> Can you think of anything I can try?
>
> By the way, the last e-mail I send asking about if anyone was on the
> list was not me being impatient, but frustration talking -- and truly
> wondering whether the list had gone cold.
>
>
> Andy
>
> _______________________________________________
> Clfs-support mailing list
> Clfs-support at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-support-clfs.org/attachments/20080325/3a403f56/attachment-0001.htm>