mingw build
As Sylvain Beucler noted some time ago, a mingw cross-compile of Guile currently fails for several reasons. The first of them is: $ CPPFLAGS=-I/usr/local/cross-tools/i386-mingw32msvc/include \ LDFLAGS=-L/usr/local/cross-tools/i386-mingw32msvc/lib \ ./configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu [...] checking for restartable system calls... configure: error: cannot run test program while cross compiling The problem apparently lies in configure.in, macro AC_SYS_RESTARTABLE_SYSCALLS Note that the autoconf documentation deprecates this macro: These days portable programs [...] should not rely on `HAVE_RESTARTABLE_SYSCALLS', since nowadays whether a system call is restartable is a dynamic issue, not a configuration-time issue. I commented it out for a start. I agree with Sylvain's suggestion of removing AC_SYS_RESTARTABLE_SYSCALLS, so propose to do that (with everything related to it). If I'm understanding correctly, the key point here is that AC_SYS_RESTARTABLE_SYSCALLS is bogus, in the sense that a program that assumed that all syscalls were restartable would always be wrong - because the handling for a given signal might be configured without the SA_RESTART flag. In addition - we take no notice of AC_SYS_RESTARTABLE_SYSCALLS when building with pthreads (which is how Guile builds by default) - we'll get a nice bit of code simplification from removing this. Any comments or objections? Thanks, Neil
a couple bugs related to error reporting and backtraces
Hi, I've got this trivial module definition in file a.scm: (define-module (a) #:export (ap)) (define (ap) (not-bound)) (ap) intended to cause an error upon calling `ap'. First bug is when trying to `load-compiled' a non-go file: scheme@(guile-user) (load-compiled ./a.scm) Backtrace: In unknown file: ?: 0* [#vm b7ade680 #program b798ec20 at unknown port:0:0 ()] 1: 1* [#program b798ec20 at unknown port:0:0 ()] ?: 2* [load-compiled/vm ./a.scm] ERROR: In procedure make_objcode_by_mmap: ERROR: Success scheme@(guile-user) As you can see, the error key, Success, is not correct. This happens with any non-go file (so the contents above is not relevant). So let's compile and load the real file: scheme@(guile-user) ,i (system base compile) scheme@(guile-user) (load-compiled (compile-file /home/jao/tmp/a.scm)) Backtrace: In unknown file: ?: 0* [#vm b7a8a680 #program b793ed70 at unknown port:1:0 ()] 2: 1* [#program b793ed70 at unknown port:1:0 ()] ?: 2* [load-compiled/vm /home/jao/.guile-ccache/1.9//home/jao/tmp/a.scm.go] ?: 3* [ap] ERROR: In procedure module-lookup: ERROR: unbound variable: not-bound scheme@(a) As you can see, the location of the error is not reported; with the same behaviour when calling the program interactively: scheme@(a) ap #program ap () scheme@(a) (ap) Backtrace: In unknown file: ?: 0* [#vm b7a8a680 #program b6f102f0 at unknown port:3:0 ()] ?: 1* [ap] ERROR: In procedure module-lookup: ERROR: unbound variable: not-bound scheme@(a) Adding the directory containing a.scm to Guile's load path changes nothing. What i was expecting is a backtrace pointing me to the location of the call to `not-bound' in a.scm. Am i doing something wrong? Thanks! jao
LGPLv3?
Hi, Some motions were made to switch to LGPLv3. I think it's a good for Free Software if Guile switches to LGPLv3. Shall we update copyrights before Friday's release? Andy -- http://wingolog.org/
