It's alive. Alive!

Buildroot failed to compile last night, but at least I know why. Debian testing apparently has three different versions of gcc installed: 3.3, 3.4 and 4.0. 4.0 is the default and apparently trying to build gcc 3.4.2 and its support libraries with a new gcc is not something that works. Once I had forced buildroot to use gcc 3.4 I was able to complete the buildroot process. I have to give the uClibc guys credit - the process works pretty well. Once you're done you have uClibc for your target, a complete suite of cross-compiler tools, a working BusyBox and potentially a lot of other goodies if you've enabled them. I did a quick check and out-of-the-box I get a libc that's about 300kB, which is pretty good compared to the 1.1MB of glibc. It's not as good as the one in flash however, which is a measly 189kB. The difference is likely due in part to unnecessary features in the default build and in part to the fact that I built uClibc 0.9.27 while the one in flash is 0.9.12. The same is true for BusyBox - they have 0.60.2 and I've got 1.1.3 (and all kinds of things enabled).

At least I am making progress. All the libraries that wmamp needs recompiled without any problems, and there is only one issue with wmamp itself: it uses strverscmp(), which does some very cool things, but is a GNU extension to glibc. It looks like uClibc should/can support it but so far I haven't been able to link wmamp unless I substitute strcmp() , and for now that is okay.

I've been able to create an image with all the uClibc stuff, but getting it all to work has been tricky. The two versions of uClibc are in no way compatible, and so once I start trying to symlink the new libc in place programs (like busybox) start failing. Since I can't replace the files in flash (yet), I need a way to be able to create all the symlinks to the new libc files without the application doing the symlinking failing. The solution for now is a statically-linked BusyBox. When the image loads the new BusyBox replaces the old one and creates all the necessary symlinks. Once those are in place a new process can be forked that uses dynamically linked programs and they will work as they should. This is a bad hack - the resulting BusyBox comes in at over 500kB, and so just about any uClibc savings are lost. This could be handled better with a purpose-built application, but since this is just a work-around until more of the boot enviroment can be replaced, it hardly seems worth doing. Right now I think the more productive route is to prune BusyBox and uClibc down a little. I know that the default builds for both include many features that have no use on this device.