<mark_weaver>Madsy: one issue is that when cross-compiling, the autoconf tests can't work properly. They might be making wrong guesses. <Madsy>Afaik, there isn't any alternative makefile for libgc, but sure <Madsy>I've done my best to inspect the configure logs <Madsy>For w32-pthread I've tested prebuilt binaries just to be sure <Madsy>The only other makefile I've seen recommended for libgc is Makefile.direct, but it seems like it is made for MinGW on Windows <Madsy>mark_weaver: Also, the libgc tests pass. That has to count for something. <Madsy>And the deadlock in guile happens consistently in the same place, both on Vista 32-bit and Windows 7 64-bit <Madsy>So I'm getting more certain this is a bug with guile. If it isn't, then the libgc and w32-pthread tests are lacking <mark_weaver>I think it's premature to make predictions about where the bug is, but in any case, we need to know what the bug is in order to fix it. <mark_weaver>if there's a deadlock, we need more information about which locks are involved. <mark_weaver>regarding autoconf tests, I was actually referring mostly to guile's configure script, which tests for several functions in libgc. <Madsy>I have a stacktrace and gdb log. It consistently happens inside GC_grow_table, invoked by scm_init_strings <mark_weaver>probably most (or all) of the GC_* functions that it looks for will be in 7.2e, but it might be assuming that they're not present. <mark_weaver>Madsy: thanks, but that's still not enough information. <mark_weaver>For starters, 'scm_init_strings' does a lot of stuff. it calls 'scm_i_make_string', and also a bunch of other initializers from libguile/strings.x. which of these things was it doing when it got stuck? <mark_weaver>scm_i_make_string uses scm_i_pthread_once, and does allocation within the associated init function 'init_null_stringbuf'. Is that where the deadlock is happening? <Madsy>Nope. It happens deep inside a call to scm_string_to_symbol called at strings.x line 21. As far as I know, the last good call is to GC_grow_table which never returns. I tried to set a breakpoint there. <Madsy>I'll try building 2.0.9 tomorrow and see if I have any luck there. But I'm currently out of ideas until someone can confirm whether my GC library is fine or not :) <davexunit>so I started using guile-json and I like it, but I don't like that JSON objects are represented as hash tables instead of alists. <davexunit>and I found quite a long thread on the ML in which hash tables were argued about at length. <davexunit>and I still can't tell whether or not hash tables were the right choice for guile-json <davexunit>to me they are a suboptimal choice because they aren't as convenient to inspect as alists. <janneke>anyone have a nice piece of elisp for me to do: (or (geiser-edit-symbol-at-point) (find-tag)) bound to M-. ? <wingo>jao doesn't seem to be around <dsmith>wingo, Morning greets. BTW, I get the exact same numbers in the signals.test ERROR messages on my 32bit laptop and the 64 it machine at work. ***cluck` is now known as cluck
<Madsy>mark_weaver: You might have been right yesterday. I found out guile's ./configure didn't pick up _GC_pthread_cancel, _GC_pthread_exit or _GC_pthread_sigmask. <Madsy>That might have something to do with it. I'll investigate that tonight. <Madsy>Which is weird, because I checked w32-pthread's exports, and it has pthread_cancel and pthread_exit <Madsy>Though I know that pthread_cancel can't actually cancel blocking threads on Windows without an additional driver <Madsy>I'll have to check if I can get w32-pthread to build with sigmask support as well <Madsy>I thought the testsuite I ran tested those functions. So sorry if I was bold/assertive yesterday <mark_weaver>Madsy: ./configure tests most of those things by compiling little test programs and running them. obviously that can't work when cross-compiling, so it makes a guess. <Madsy>mark_weaver: Actually it doesn't run the programs. It only checks if gcc returns 0 or not <Madsy>So it's not guile ./configures fault. libgc didn't export those functions for some reason I've yet to figure out <mark_weaver>maybe libgc's configure didn't find them for a similar reason? <Madsy>I didn't find any relevant flags in libgc's config.log. I must be missing a #define used in gc.h or similar <Madsy>I'm writing down all my efforts. Maybe that would be nice to have in the INSTALL or README file <mark_weaver>given how cheap libgc is to build, I'd think that it would be worth checking to see if it exports those missing functions before digging into the libgc source code. <mark_weaver>I wonder if we should switch to using the gnulib threadlib, which has backends for posix threads, GNU Pth threads, solaris threads, and Windows threads. <mark_weaver>what's wrong with this URL? wget handles it properly. <didi>mark_weaver: There are too `http's. <didi>mark_weaver: Ask http-get. <mark_weaver>these are the URLs used by the internet wayback machine. and incidentally, the reason I'm using that is because Hans Boehm's website at HP has been down for a while. <wingo>there is a new web site fwiw <wingo>but that's still a bug to uncover :) <wingo>i found that using my newfound magical power of email <wingo>mark_weaver: i assume you saw the gnutls bug; nasty stuff! <mark_weaver>ooh, thanks for reminding me. time to upgrade the version in guix