Hi, Ludovic Courtès <[email protected]> skribis:
> Christopher Baines <[email protected]> skribis: > >> Following up on this, I've built Guile on core-updates with libgc@7 >> rather than libgc@8 (which is what's used above), and I can't reproduce >> the issue. So, I'm getting more certain that this is a regression which >> the libgc upgrade has led to. > > Bah. :-/ > > We noticed similar issues with libgc@8 earlier but it seemed to be > fixed: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812 > >> Would it be feasible to keep guile, or at least the guile Guix uses with >> libgc@7 for now? > > Yes, we can define a Guile variant in (gnu packages guile) and have > (guix self) refer to it. FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash upstream and gathered more info: https://github.com/ivmai/bdwgc/issues/353 On #guile they also mentioned that libgc 8 defaults to ‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’. Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487, I changed libgc 8 so it’s built with ‘--disable-munmap’. This relieves the need for ‘guile-3.0/libgc-7’. (I checked with “make as-derivation” on x86_64-linux that those derivations that would previously fail with libgc 8 no longer do.) Ludo’.
