Andy Kennedy wrote: > 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 > > > To provide more information about this issue, I just reinstalled the CLFS system to a USB stick and attempted to chroot into it. . . survey says: [EMAIL PROTECTED] ~# chroot /jumpdrive Segmentation fault which leads me to believe that I have a bad build on the native Glibc? Using the cross-tools as the clfs user, I can statically compile a hello world, but I have no library to link to to attempt a dynamic version.
Again, any help will be greatly appreciated. Andy _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
