Russell King writes: > On Tue, Sep 25, 2001 at 01:02:10PM -0500, Cam Mayor wrote: > > I grabbed cross-2.95.3.tar.bz2 from > > ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain and installed it in > > /usr/local/arm/2.95.3. It compiled a simple helloworld.cpp file with > > arm-linux-g++, and i put it in a local tmp directory that is > NFS mounted on > > my CDB89712 machine. > > It depends where the C library was told its final resting place will be. > > Basically, if ld-linux.so.2 isn't in the place the binary expects, you get > a "No such file or directory" error. You can find out where it expects to > be by doing: > > objdump --full-contents --section=.interp a.out Thank you, Russell. I see the direction of my problem now. I had absolutely no shared libraries on the target system. Actually, i hadn't thought of it, as the gcc compiler i was formerly using did nice tight little statically linked binaries by default, and the "No such file" message confused the heck out of me. (and groups.google.com didn't turn up much relevant info) I toyed with a few ideas on how to quick-fix this. I used the objdump command to find what libraries it needed, then dumped it and some friends into the target (live) ramdisk. I got segmentation faults, but at least it went somewhere. I tried dumping *all* the libs into the target's ramdisk but quickly ran out of room. I wasn't sure if dropped-in libraries would work, anyway. Erik, if you get to read this, i humbly suggest you add something describing what to do with the shared libraries (if the binary is destined for another system) to the README file that was in the same dir as the cross compiler (as listed above). It caught me unawares, and will no doubt catch some others, even thought it might seem obvious. Since the system for which we are developing will be mostly single-function units, we can get away with having a few statically compiled binaries instead of shared ones. That being said, i was wide-eyed-surprised that when compiled statically, my code that only included <iostream> and <limits.h> resulting in a binary that jumped from 308k (shared) to 1.7meg (static). whew! i better turn on some space optimization. :-) In my development environment i generally mount local drives via NFS to run binaries on my arm. Looking at the large size, i decided to throw it into a ramdisk image and upload it to see if it fit. It didn't...or at least something unfavourable happened. :-( As usual, problem solving is like playing whack-a-mole. For the hermit bootloader users/developers out there, the specific error received was "Uncompressing ramdisk....-NG assertion failure at gunzip.c:109: hermit_free_mem_ptr + size <= hermit_free_mem_ptr_end" Although, if i'm right about what i think it is telling me, the '<' should be a '>'. I am assuming it was trying to tell me it ran out of space into which it could decompress the ramdisk. Is the kernel-compiled setting Block devices->Default RAM disk size (default is 4096) my limiting factor, or is something compiled within hermit? I have seen a few people ask about max ramdisk size on the linux-arm-* lists. I have posed a similar comment/question a few times in response, but with no takers. Is the 4096 in bytes or kilobytes? (it doesn't say in the kernel config help) Odd that i'd have a problem since uncompressed, my uploaded ramdisk is only 2.3 meg. Hmmm...maybe i should restate these specific questions on the linux-arm-kernel list. cheers, cam _______________________________________________ http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm Please visit the above address for information on this list.
