Currently we're concentrating more on using glibc than uClibc because it is already difficult enough to develop
scratchbox using "known to work" components. This applies to target software development also. At the moment it might
be best to first make sure your application works with glibc, and only then test it with uClibc (if that is your target
environment). This is of course highly dependent on your particular requirements.
2. Debug your software instead of the tools used
You shouldn't spend serious effort in testing your software against non-standard C-libraries or other non-standard
versions of standard system components until your software has been verified to work correctly. You should do testing
in an environment and with tools that are known to work together (Linux desktop, standard kernel, glibc, Valgrind etc).
Debugging problems in your tools instead of problems in your own software is not productive. Don't do it until you have
to.
