<mark_weaver>there are many things that could be happening here. I told you what I need if you want my help. <mark_weaver>a huge complex pile of code that doesn't work is not something I'm willing to look at, sorry. <mark_weaver>if after-gc-hook is not getting called, then maybe that's because the GC doesn't realize how much memory has been allocated. this can happen, for example, if you have a large amount of memory allocated outside of libgc (e.g. malloc) that's being kept alive by a much smaller amount of GC-allocated memory. <mark_weaver>the scenario here is that you arrange for the large blocks allocated outside of libgc (e.g. malloc) to be freed by a finalizer on the much smaller libgc-allocated block. <mark_weaver>ideally, such blocks would be allocated using scm_gc_malloc, but if that's not feasible for some reason (e.g. you don't control the code that does the allocation), then see scm_gc_register_allocation.. <mark_weaver>of course, there are many other possibilities, e.g. you are corrupting some memory somewhere, or otherwise violating a contract. <mark_weaver>or, if it *is* a bug in guile, then I need either a minimal self-contained example that demonstrates the problem, or else the results of "git bisect". ***dje is now known as dje42
***christop1 is now known as christoph_debian
<mthl>Does anyone know if static functions in C can cause problem if registered with 'scm_c_define_gsubr' and then called from scheme? <mthl>amz3: sorry i miss your answer <mthl>if embedding guile means using scm_boot_guile, yeah it's what I'm doing. <mthl>(info "(guile-2) Linking Guile into Programs") gives me an implicit answer <daviid>rotty: fyi, i see g-wrap 1.9.15 landed in debian testing, but it seems its guile-library dependency hasn't been updated to 0.2.2 [it still refers to 0.1.1] <rlb>I've been tracking down some problems with Debian 2.0.11-9 on armel with gcc 5, and I may have figured out a workaround, but I though I'd ask if there are any known issues there? <rlb>(I think the original build problem was being caused by debian/rules bugs that prevented the addition of -O2 - in which case it fails with a compiler offset error. I've fixed that and am working on some test issues.) <civodul>rlb: i think we always build with -O2; building with -O0 used to cause problems <rlb>Right, I'm seeing other issues with -O2 now - tracking them down. Need to get this fixed - otherwise guile will be the only thing holding the old compiler(s) in Debian. <rlb>I suspect the "other issues" might be related to Debian's default (armel) build flags. <rlb>We'll see. Each test cycle takes quite a while on ARM. <rlb>(Would still be slow on x86, but not as slow.) <civodul>2.0.11 builds fine for us on armhf (armv7) <rlb>right, and the issue is on armel, armhf is fine <rlb>Though I wonder what's going to happen when I switch all the archs over to the correct build flags... <rlb>np - the bit I'm investigating now might be broken on armhf too for all I know. But the current debs build fine on armhf. <rlb>Debian adds various flags by default (cf. dpkg-buildflags) <rlb>but the current debs don't use that (yet) <rlb>CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security <rlb>CPPFLAGS=-D_FORTIFY_SOURCE=2 <rlb>for example, on armel <rlb>OK, so a clean tree build with dpkg-buildflags was fine (passed all tests but the version.test). Must be something else about the Debian changes. <rlb>(or the build process) <rlb>wonder if fakeroot might be a problem for any of the tests on armel... <rlb>ACTION reviews debian/patches/