NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Mounted root (jffs2 filesystem) readonly. Freeing init memory: 72K INIT: version 2.86 booting Vendor: CBM Model: Flash Disk Rev: 5.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 2067968 512-byte hdwr sectors (1059 MB) sda: Write Protect is off sda: assuming drive cache: write through SCSI device sda: 2067968 512-byte hdwr sectors (1059 MB) sda: Write Protect is off sda: assuming drive cache: write through sda: sda1
Book: CLFS-Sysroot-SVN-0.0.1-20080121 HOST: x86 Slackware 12.0 install (Glibc 2.6) Target: Arm XScale As seen from the above, the Linux kernel continues to control the system, however, INIT never does anything other than the one printf(). I have attempted this several different ways so far. One way I attempted this was to build a static BusyBox (linked against uClibC) to get mount, ls, cp, and a very few other utilities. Next, I allow my old system to boot into the 2.3.2 Glibc system. I then use NFS to attach the freshly built CLFS to the target (via the mount command which is the static BusyBox). I connect in and can busybox ls /usr /bin /sbin /lib and see all the files I expect. Next, however, I do a ls and I hang, just like on the init. Thinking that the dynamic linker just didn't get re-homed correctly, I attempted to build the system to boot off of USB, which I did and booted into the system. init hangs. Thinking that I was doing something sloppy with the USB, I carefully built a 32MB jffs2 image (/usr would be via USB device) and attempted to bring up the system that way. Again, no luck and init only hangs. Thinking that the init had some issues with it I built BusyBox 1.9.1, dynamically linking it to the sysrooted Glibc. Same thing. However, when I statically linked BusyBox with the Glibc (not following the full instructions from the BusyBox build -- I didn't have to removed the gcc switches, just the #error from within the one file) I was able to get BusyBox to start. The inittab was extremely off for this version of BusyBox, therefore I was unable to see anything other than /dev/**** was not found (**** was a continuous loop of l0-l9 S0, etc). This may have meant that I may have been able to get that one to run. But the bottom line question still remains: Why can I not get a dynamically linked program to run under the cross-compile system? Any light you can shed on this would be greatly appreciated. Andy _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
