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.
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.