<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For host==target you can chroot into the build/root-filesystem-$ARCH<br>
directory, which should let you run gdb on a process. (I believe you can<br>
attach by PID and see where it's spinning, with stack backtrace and<br>
everything.)<br>
<br>
But if uClibc's NPTL doesn't "just work" for a target (not just a<br>
configuration issue but needing nontrivial debugging), the best course<br>
of action is probably for me to finish the musl migration for the<br>
supported targets. (Of which x86-64 should be one.) uClibc is sort of a<br>
dead-end project (Despite the existence of the various uClibc-ng forks.)<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br></font></span></blockquote><div><br></div><div>It seems to be distcc. Perhaps there's a network/Qemu problem of some kind. If I remove distcc from the path then it's fine. Is there a simple way to disable distcc when running dev_environment.sh?</div><div><br></div><div>Nevertheless, switching to musl is a good idea IMHO. </div></div><br></div></div>