Ian,
You don't mention a platform so I will assume Linux.
GNU make 3.81 dates from 2006, and 3.82 was released in 2010. That's a lot of bugfixes, so the first thing is to try at least 3.82 and ideally the CVS version which has ~3 more years of fixes. Building the CVS versions is not hard if you have a fairly modern system which either has or allows you to add a couple of required packages (see the README.cvs file). I suggest turning off any -O flags and adding -g; not only does this improve debugging and stack dumps but there's a class of subtle bug which can be triggered by optimization.
If you still see the problem with the CVS version (which identifies as 3.82.90 under --version) then you could try looking at what the process is doing. The way I often start in situations like this is to "echo $$" in the window where you plan to run make, to get what will be its parent pid. Then run make, and in another window run something like "pstree -a -p -l <pid>" with that parent pid you collected. This should clarify the process tree situation; either make will be stuck internally (no new children) or will be waiting on some subprocess which doesn't return. Though in this case it seems fairly clear there are no new processes.
Assuming the hang is within make, you could try forcing a core dump. This can be done with kill -BUS (or there may be a better way, Linux is not my native country). Something else to try first would be "strace -p <make-pid>". This may generate a lot of data but there may be a cycle which provides a clue. Or make may just be sleeping, waiting for some resource, in which case strace should help figure out what that resource is.
These may provide useful clues. However, based on the data you provided I'd bet on a bug in make and your best hope is that it's been fixed in the last ~7 years.
David Boyce