This is probably a sign that I'm missing something, but I searched a bit and didn't see it.

I checked out Kamikaze (svn 10567) and tried to build it up from scratch.  Went through the menuconfig process, left everything pretty much default.  When I try to build it, it gets as far as tools/automake compile, then hangs.  Here's the transcript::

jrd@mothra ~/openwrt/kamikaze/trunk $ make
make[1] world
make[2] tools/install
make[3] -C tools/sed compile
make[3] -C tools/sed install
make[3] -C tools/sstrip compile
make[3] -C tools/sstrip install
make[3] -C tools/ipkg-utils compile
make[3] -C tools/ipkg-utils install
make[3] -C tools/genext2fs compile
make[3] -C tools/genext2fs install
make[3] -C tools/lzma compile
make[3] -C tools/lzma install
make[3] -C tools/squashfs compile
make[3] -C tools/squashfs install
make[3] -C tools/mtd-utils compile
make[3] -C tools/mtd-utils install
make[3] -C tools/mkimage compile
make[3] -C tools/mkimage install
make[3] -C tools/firmware-utils compile
make[3] -C tools/firmware-utils install
make[3] -C tools/patch-cmdline compile
make[3] -C tools/patch-cmdline install
make[3] -C tools/pkg-config compile
make[3] -C tools/pkg-config install
make[3] -C tools/automake compile

Not really clear what it's doing; the machine appears to be idle.  Anybody seen this?  What am I doing wrong.  TIA....

You can check the process status (using ps axw) as well as the CPU usage (using top) to find out if this compilation is stuck.

(Last edited by mazilo on 8 Mar 2008, 18:14)

Yes, as in first post, machine is essentially idle.  load avg < 0.01, no IO, no apparent activity at all outside the usual OS and daemons.  It's as if the build process has stopped for input, but it's not waiting on stdin.  Not clear what's happened to it.

ps sez there's something running an extremely long command line, which appears to be boiling down to a cp.  The beginning of that line is

bash -c . /net/kong/raid/1/home/jrd/openwrt/kamikaze/trunk/include/shell.sh; eval "$2" -- -c (cd /net/kong/raid/1/home/jrd/openwrt/kamikaze/trunk/build_dir/host/automake-1.9.6/; [ -x configure ] && cp -fpR ....

No further progress.

(Last edited by jrd on 8 Mar 2008, 19:01)

Things you can try:
Run "pstree -p" to see if you can find the process that's stuck.  Get the process ID.  Then run "strace -p process-ID" to see if it's doing anything.

Kill the build and run "make V=99" instead of just "make".  This will tell you what's happening.

Things that sometimes have that sort of effect:
1.) It might be downloading some large file.
2.) It might be waiting for input.  It shouldn't be, but it does sometimes happen in trunk.

make V=99 says

make[3]: Entering directory `/net/kong/raid/1/home/jrd/openwrt/kamikaze/trunk/tools/automake'
checking build system type... i586-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for perl... /usr/bin/perl
checking for tex... no
checking whether autoconf is installed... yes
checking whether autoconf works...       

tracking down the process reveals that it's autom4te

strace'ing it, oddly enough, generates a bunch of output, then hangs, as

write(4, " -f -r conftest* confdefs.h\n\n# P"..., 3964) = 3964
close(4)                                = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
_llseek(3, 0, [0], SEEK_CUR)            = 0
ftruncate64(3, 0)                       = 0
write(3, "# This file was generated.\n# It "..., 2619) = 2619
close(3

Control-c'ing the strace causes the autoconf to un-hang!

There's something fairly peculiar going on here.  The fact that the strace gets it unstuck is rather suspicious.  The host machine is a pentium box running gentoo, emerged up to date as of last week.  I would be tempted to say that something pretty low-level like the kernel or glibc or something is wacked, except that I've compiled probably several hundred packages on it in the last few weeks, most of which used autoconf and friends.  I guess I'll just plow ahead, and if it keeps happening, try to get a better handle on what the combination of circumstances is that gets it into this pickle.

Thanks for all the suggestions.

Weird. Looks like it hangs trying to close a file!

I'd recommend building latest trunk or wait for the next release and I'd only use Linux for building. 7.09 is too old...

(Last edited by forum2008 on 9 Mar 2008, 11:45)

Eh?   He is using Linux to build it.  He said he's running Gentoo.

I don't know why the close system call should block.  Maybe you should try another version of the kernel.

I found a few more instances of the automake hang.  Digging a bit further, I think what's going on is that I'm building in an nfs-mounted area, and that it's trying to use file-locking primitives, which don't work over nfs.  I remember hearing from some other gentoo hackers that autotools have got this bee in their bonnet about locking.  I'm starting over with a fresh checkout on the local disk, so far that seems to be working better.

Thanks...

Ah ok that makes more sense. Do you have rpc.lockd and statd running? Probably safest to avoid nfs for the build anyway.

Yes, checked that those were running, but seems not to matter.

One of my buds, while explaining the screw case, tried to elucidate why what autotools is doing is different than a bunch of other stuff, but I'm not sure I got all the nuances.  It doesn't matter, if using local disk instead of nfs constitutes a workaround, that's fine.