> Date: Thu, 20 Mar 2014 11:34:53 +0100 > From: Panicz Maciej Godek <godek.mac...@gmail.com> > Cc: bd...@lists.opendylan.org, "guile-user@gnu.org" <guile-user@gnu.org> > > >> I did remove the only reference to mkstemp.c that appeared in the > >> Makefile.am, then run autoreconf and configure, but it turned out that > >> there were still some dependencies on libguile_2.0_la-mkstemp.o in the > >> generated libguile/Makefile. After removing those, I went through that > >> part of compilation, but the process stalled on the GEN > >> guile-procedures.texi. > > > > OK. How long did you wait? That part can take a bit of time (I'd say > > 30s to 1mn maybe) because it runs the yet-to-be-compiled Guile. > > I decided to run the whole process once again, and GEN > guile-procedures.texi has been running for almost an hour now, and it > clearly uses no CPU. > > I had a "process hacker" tool installed, and it allows me to do some > introspection (although I understand very little). There are two > threads running in the "youngest" guile.exe (#2820), the first one > with start address > guile.exe+0x1570 > and the second with > msvcrt.dll!endthreadex+0x3a > > When I inspect the first thread, I get: > > 0, ntkrnlpa.exe!KiDeliverApc+0xb3 > 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae > 2, ntkrnlpa.exe!NtWaitForSingleObject+0x38c > 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14 > 4, ntdll.dll!KiFastSystemCallRet > 5, kernel32.dll!WaitForMultipleObjects+0x18 > 6, pthreadGC2.dll!pthreadCancelableTimedWait+0x4b > 7, pthreadGC2.dll!sem_timedwait+0x16f > 8, 0x79a50 > > The inspection of the second thread shows: > > 0, ntkrnlpa.exe!KiDeliverApc+0xb3 > 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae > 2, ntkrnlpa.exe!NtWaitForSingleObject+0x9a > 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14 > 4, ntdll.dll!KiFastSystemCallRet > 5, ntdll.dll!RtlEnterCriticalSection+0x46 > 6, ntdll.dll!KiUserApcDispatcher+0x7 > > When I use the "analyze > wait" option on the first thread, I get: > Thread is waiting (alertable, wait all) for: > Handle 0x79a50 (Semaphore): (unnamed object) > Handle 0x7b4 (Event): (unnamed object)
Isn't this the same problem I reported last year, starting here: http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html I suggest to configure Guile --without-threads, and see if that resolves the issue.
