From: Brian Gerkey <gerkey@AI.SRI.COM> - 2006-02-07 18:06:42
I'm new to gumstix programming and have run into a strange problem:
anything that I cross-compile segfaults immediately when I execute it
on the gumstix.
Example program, compiled as 'foo':
On the gumstix:
# ldd foo
ldd: can't open cache '/etc/ld.so.cache'
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4000d000)
libc.so.0 => /lib/libc.so.0 (0x4001e000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
When I run it:
So far, I checked out the buildroot from SVN, changed
INSTALL_LIBSTDCPP to true, and built it. I used the resulting arm-
linux-gcc to compile the above program. I'm building on a 64-bit x86/
Linux machine. I scp the binary to the gumstix and run it.
One thing I've noticed is that the libs onboard the gumstix are
version 0.9.27, whereas the libs in my freshly checked-out builldroot
are 0.9.28. Is that the problem? If so, what's the easiest way to
update the onboard libs?
Brian P. Gerkey gerkey@...
SRI AI Center http://www.ai.sri.com/~gerkey
On Feb 7, 2006, at 9:38 AM, Brian Gerkey wrote:
> One thing I've noticed is that the libs onboard the gumstix are
> version 0.9.27, whereas the libs in my freshly checked-out
> builldroot are 0.9.28. Is that the problem? If so, what's the
> easiest way to update the onboard libs?
That is precisely the problem. There have been one or two threads on
this in the last day or so on the list -- it turns out the uClibc
broke binary compatibility with 0.9.27 when it moves to 0.9.28;
genius user-friendly move that that is. I'm looking now at whether
turning on the "0.9.27 compatibility" option in the uclibc build
resolves this problem.
In the meantime, the easy workaround is to just reflash the root_fs
built from the buildroot onto the gumstix, by following the
instructions on the wiki. It's quite easy to do, and it will bring
your system up to 0.9.28.