bug#39395: GOOPS generic promotion fails for nary functions
Rob Browning writes: > And then I found that the the manual says this: > > If symbol was previously bound to a Scheme procedure (or > procedure-with-setter), the old procedure (and setter) is incorporated > into the new generic function as its default procedure (and setter). > > So I wondered if this might be a bug, or was expected behavior. It's > also easy to work around -- just change the first define to a > define-method. Not sure if this might be related. With guile-3.0 (use-modules (oop goops)) (define x close) (define-generic x) produces: $ guile-3.0 -s test.scm ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/rlb/test.scm ;;; /home/rlb/test.scm:5:0: warning: shadows previous definition of `x' at /home/rlb/test.scm:4:0 ;;; compiled /home/rlb/.cache/guile/ccache/3.0-LE-8-4.2/home/rlb/test.scm.go Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
bug#39118: Segfault while building on 64-bit Cygwin
On 2/6/20, Andy Wingo wrote: > Given that John said that compilation went fine with > GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed > in the past. My suspicions are that this issue is an ABI issue with > lightening that could perhaps be reproduced by: > > git co https://gitlab.com/wingo/lightening > cd lightening > make -C tests test-native > > Of course any additional confirmation is useful and welcome! I haven't been able to get guile to compile under Cygwin (just a compilation error I haven't had time to track down), but I was able to quickly try the above. I get: Testing: test-native-call_10 call_10.c:9: assertion failed: e == 4 /bin/sh: line 1: 7063 Aborted (core dumped) ./$test make: *** [Makefile:31: test-native] Error 134 Despite what it says about a core dump, I find no such thing. Just a file with the same name as the executable suffixed with ".stackdump". (I did attempt to configure the Cygwin dumper before running the tests.) Unless somebody suggests otherwise, I think the error message is more useful. -- Charles
bug#36811: Guix fails to build with libgc 8.0.4
On 06.02.20 15:07, Ludovic Courtès wrote: Hi Jonathan, As discussed yesterday on #guix, I tried this: guix build guile3.0-guix --with-input=libgc@7=libgc@8 as of Guix commit 9d0dfd9a9a7c43363a4e140c20d49f119fe6f2e3. Guile 3.0.0 itself builds fine (test suite included), but the build of Guix crashes like this (on x86_64-linux-gnu): --8<---cut here---start->8--- [ 76%] GUILEC gnu/packages/icu4c.go [ 77%] GUILEC gnu/packages/idris.go [ 77%] GUILEC gnu/packages/idutils.go [ 77%] GUILEC gnu/packages/image.go [ 77%] GUILEC gnu/packages/image-processing.go [ 77%] GUILEC gnu/packages/image-viewers.go mmap(PROT_NONE) failed /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line 7: 26886 Aborted XDG_CACH E_HOME=/nowhere host=x86_64-unknown-linux-gnu srcdir="." ./pre-inst-env /gnu/store/dcsjagbjlhjj40g30lb88wx3zybmh07g-gui le-next-3.0.0/bin/guile -L "." -L "." --no-auto-compile -s "."/build-aux/compile-all.scm guix/base16.scm guix/base32.sc m guix/base64.scm guix/ci.scm guix/cpio.scm guix/deprecation.scm guix/docker.scm guix/json.scm guix/records.scm guix/pk --8<---cut here---end--->8--- This is exactly the error I see on Tumbleweed and what this issue is about :) This is good, so I guess it also has the same root somewhere in guile<->libgc8. Apparently the message and abort come from ‘GC_unmap’ or ‘GC_unmap_gap’ in libgc, but I have no idea what to think about it. Could it be a heap exhaustion issue or similar? That’s not impossible. Thanks for providing the reproducer!
bug#36811: Guix fails to build with libgc 8.0.4
Hi Jonathan, As discussed yesterday on #guix, I tried this: guix build guile3.0-guix --with-input=libgc@7=libgc@8 as of Guix commit 9d0dfd9a9a7c43363a4e140c20d49f119fe6f2e3. Guile 3.0.0 itself builds fine (test suite included), but the build of Guix crashes like this (on x86_64-linux-gnu): --8<---cut here---start->8--- [ 76%] GUILEC gnu/packages/icu4c.go [ 77%] GUILEC gnu/packages/idris.go [ 77%] GUILEC gnu/packages/idutils.go [ 77%] GUILEC gnu/packages/image.go [ 77%] GUILEC gnu/packages/image-processing.go [ 77%] GUILEC gnu/packages/image-viewers.go mmap(PROT_NONE) failed /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line 7: 26886 Aborted XDG_CACH E_HOME=/nowhere host=x86_64-unknown-linux-gnu srcdir="." ./pre-inst-env /gnu/store/dcsjagbjlhjj40g30lb88wx3zybmh07g-gui le-next-3.0.0/bin/guile -L "." -L "." --no-auto-compile -s "."/build-aux/compile-all.scm guix/base16.scm guix/base32.sc m guix/base64.scm guix/ci.scm guix/cpio.scm guix/deprecation.scm guix/docker.scm guix/json.scm guix/records.scm guix/pk --8<---cut here---end--->8--- Apparently the message and abort come from ‘GC_unmap’ or ‘GC_unmap_gap’ in libgc, but I have no idea what to think about it. Could it be a heap exhaustion issue or similar? That’s not impossible. Thanks, Ludo’.
bug#39118: Segfault while building on 64-bit Cygwin
On Mon 20 Jan 2020 18:22, Mike Gran writes: > On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote: >> Yes, gladly, but I don't know how to get one in this context. Do I need to >> add some flags to the Makefile, and if so, where? (It's a twisty maze of >> passages, all different.) . Note that this *is* a build with JIT enabled; >> when I disable it using the env variable, there are no errors and 3.0.0 >> works fine. >> >> Also, it may take some time, as I have to rebuild my Windows system. > > I also tried building Guile 3.0.0 on Cygwin 3.1.x. The failure comes from > trying to parse compiled .go files. > > The last time that I had this sort of problem, it was because the > O_BINARY flag was dropped or missing when writing .go files, leading > to CR+LF characters in the compiled files. And I diagnosed it by > byte-comparing Linux-compiled .go files with Cygwin-compiled .go > files, and by looking for CR+LF combinations in the compiled .go > files. > > I don't know if that is what is happening here, but, I'll check that > next time I have a chance. Given that John said that compilation went fine with GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed in the past. My suspicions are that this issue is an ABI issue with lightening that could perhaps be reproduced by: git co https://gitlab.com/wingo/lightening cd lightening make -C tests test-native Of course any additional confirmation is useful and welcome! Cheers, Andy
