Thanks Dave!  Your suggestion to remove build_arm_nofpu and toolchain_arm_nofpu before kicking off the new build did the trick.

Todd


On 10/4/06, dhylands@alumni.sfu.ca <dhylands@alumni.sfu.ca > wrote:
Hi Todd,

> I just upgraded from 2.6.11 to 2.6.18 to get hotplug/udev improvements.  I
> updated buildroot using 'svn update', rebuilt buildroot, and then
reflashed
> a GS with the 2.6.18 rootfs.
>
> Unfortunately at least a couple of binaries that I require no longer run
on
> 2.6.18gum. Instead I receive the runtime error:  "can't resolve symbol
> '__uClibc_start_main'" when they are invoked.  I know of sz and sdpd (a BT
> daemon) so far, but I suspect that many other binaries are also affected.
> That will be nasty.
>
> What is the recommended approach for dealing with this lib compatibility
> issue?

You need to also do:

rm -rf buildroot_arm_nofpu toolchain_arm_nofpu

What's happening is that uClibc was upgraded, and unfortunately, the new
uClibc is not binary compatible with the old one. If you don't remove the
directory trees mentioned above, then make will try to mix objects from the
old toolchain and the new toolchain. By removing those two directory trees,
you'll be removing all of the old stuff, and doing the make will regenerate
all of the objects using the same toolchain, and it everything should work
fine.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users