GNU Guile 1.8.4 released

GNU Guile 1.8.4 released

[Ludovic Courtès]

We are pleased to announce GNU Guile release 1.8.4.  This is the next
maintenance release for the 1.8 stable series.

You can find it here:

  ftp://ftp.gnu.org/gnu/guile/guile-1.8.4.tar.gz
  SHA1 hash: 1e80fe242acfde2bfa39fd1e8409a8f010e24e2b

A GPG detached signature of the package is available at:

  ftp://ftp.gnu.org/gnu/guile/guile-1.8.4.tar.gz.sig

The Guile web page is located at http://www.gnu.org/software/guile,
and among other things, it contains a link to the Guile FAQ and
pointers to the mailing lists.

Guile is an interpreter for the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively or as a script interpreter, and is also
packaged as a library so that applications can easily incorporate a
complete Scheme interpreter.  An application can use Guile as an
extension language, a clean and powerful configuration language, or as
multi-purpose "glue" to connect primitives provided by the
application.  It is easy to call Scheme code from C code and vice
versa.  Applications can add new functions, data types, control
structures, and even syntax to Guile, to create a domain-specific
language tailored to the task at hand.

This is primarily a bugfix release.  Here are the highlights, taken from
the `NEWS' file:

  - Bugs fixed

   - CR (ASCII 0x0d) is (again) recognized as a token delimiter by the
     reader
   - Fixed a segmentation fault which occurred when displaying the
     backtrace of a stack with a promise object (made by `delay') in it
   - Make `accept' leave guile mode while blocking
   - `scm_c_read ()' and `scm_c_write ()' now type-check their port
     argument
   - Fixed a build problem on AIX (use of func_data identifier)
   - Fixed a segmentation fault which occurred when hashx-ref or
     hashx-set! was called with an associator proc that returns neither
     a pair nor #f.
   - Secondary threads now always return a valid module for
     (current-module).
   - Avoid MacOS build problems caused by incorrect combination of "64"
     system and library calls.
   - `guile-snarf' now honors `$TMPDIR'
   - `guile-config compile' now reports CPPFLAGS used at compile-time
   - Fixed build with Sun Studio (Solaris 9)
   - Fixed wrong-type-arg errors when creating zero length SRFI-4
     uniform vectors on AIX.
   - Fixed a deadlock that occurs upon GC with multiple threads.
   - Fixed compile problem with GCC on Solaris and AIX (use of _Complex_I)
   - Fixed autotool-derived build problems on AIX 6.1.
   - Fixed NetBSD/alpha support
   - Fixed MacOS build problem caused by use of rl_get_keymap(_name)

  - New modules (see the manual for details)

   - `(srfi srfi-69)'

  - Documentation fixes and improvements

   - Removed premature breakpoint documentation
   - More about Guile's default *random-state* variable
   - GOOPS: more about how to use `next-method'

  - Changes to the distribution

   - Corrected a few files that referred incorrectly to the old GPL +
     special exception licence
   - Removed unnecessary extra copies of COPYING*


Any bugs found in this release will be addressed by further bugfix
releases numbered 1.8.*.

You can follow Guile development in CVS and on the Guile mailing lists
(see ANON-CVS and HACKING).  Guile builds from the development branch
of CVS will have version number 1.9.0.

Guile versions with an odd middle number, e.g., 1.9.*, are unstable
development versions.  Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.

Please send bug reports to `bug-guile@gnu.org'.


Ludovic Courtès, on behalf of the Guile team.

Re: GNU Guile 1.8.4 released

[Kamaraju S Kusumanchi]

Ludovic Courtès wrote:

> 
> Any bugs found in this release will be addressed by further bugfix
> releases numbered 1.8.*.
> 

Just wanted to bring to your attention that guile 1.8.4 failed to build on
alpha, ia64 architectures. The build log can be found at

http://buildd.debian.org/fetch.cgi?pkg=guile-1.8&arch=alpha&ver=1.8.4%2B1-1&stamp=1203917145&file=log&as=raw

http://buildd.debian.org/fetch.cgi?pkg=guile-1.8&arch=ia64&ver=1.8.4%2B1-1&stamp=1203835823&file=log&as=raw

It would be great if they can be fixed.


raju
-- 
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/

Re: GNU Guile 1.8.4 released

[Neil Jerram]

Kamaraju S Kusumanchi <kamaraju@bluebottle.com> writes:

> Just wanted to bring to your attention that guile 1.8.4 failed to build on
> alpha, ia64 architectures. The build log can be found at
>
> http://buildd.debian.org/fetch.cgi?pkg=guile-1.8&arch=alpha&ver=1.8.4%2B1-1&stamp=1203917145&file=log&as=raw
>
> http://buildd.debian.org/fetch.cgi?pkg=guile-1.8&arch=ia64&ver=1.8.4%2B1-1&stamp=1203835823&file=log&as=raw
>
> It would be great if they can be fixed.

Looking into ia64 first...  On my test machine, and without the Debian
patches, I'm seeing other problems that prevent me from reaching the
Illegal instruction that your build is getting.

One of them is: Undefined reference to .L16, when trying to link
   libguile/.libs/guile

This seems related to the use of a union, containing several different
pointer types, in uvec_print() in libguile/srfi-4.c.  Specifically, it
seems that the .L16 reference is pulled in by pointer dereferences
like the "*np.u8" in

	case SCM_UVEC_U8: scm_uintprint (*np.u8, 10, port); np.u8++; break;

If I replace "*np.u8" by "1", there is no longer any undefined
reference.
If I declare a separate variable "scm_t_uint8 *u8", and use that
instead of np.u8, there is no longer any undefined
reference.

I could rewrite the code to avoid the union, but I'd like to
understand what's going on here first.  Can anyone help?

Thanks,
     Neil

Re: GNU Guile 1.8.4 released

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Looking into ia64 first...  On my test machine, and without the Debian
> patches, I'm seeing other problems that prevent me from reaching the
> Illegal instruction that your build is getting.
>
> One of them is: Undefined reference to .L16, when trying to link
>    libguile/.libs/guile
>
> This seems related to the use of a union, containing several different
> pointer types, in uvec_print() in libguile/srfi-4.c.  Specifically, it
> seems that the .L16 reference is pulled in by pointer dereferences
> like the "*np.u8" in
>
> 	case SCM_UVEC_U8: scm_uintprint (*np.u8, 10, port); np.u8++; break;
>
> If I replace "*np.u8" by "1", there is no longer any undefined
> reference.
> If I declare a separate variable "scm_t_uint8 *u8", and use that
> instead of np.u8, there is no longer any undefined
> reference.

For the record, and future searchers, this appears to be a GCC bug in
GCC version 3.4.2.  Given the attached program (which is cut down from
uvec_print in srfi-4.c), GCC 3.4.2 gives:

$ gcc -g -O2 -Wall -Wmissing-prototypes njtest.c
/tmp/cc42dKyL.o(.text+0x20): In function `uvec_print':
/u/guest/neil/guile-1.8.4-debugging/libguile/njtest.c:23: undefined reference to `.L9'
collect2: ld returned 1 exit status

$ gcc -v
Reading specs from /export/local/ia64-linux/bin/../lib/gcc/ia64-unknown-linux-gnu/3.4.2/specs
Configured with: ./configure 
Thread model: posix
gcc version 3.4.2

But GCC 4.1.2 is fine:

$ gcc4 -g -O2 -Wall -Wmissing-prototypes njtest.c
(no output)

$ gcc4 -v
Using built-in specs.
Target: ia64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.3 --enable-libgcj-multifile --enable-languages=c,c++,java,f95 --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=ia64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)

Regards,
      Neil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: njtest.c --]
[-- Type: text/x-csrc, Size: 1024 bytes --]

#include <inttypes.h>
#include <stdlib.h>

#define SCM_UNPACK(x) ((uintptr_t) (x))
typedef struct scm_unused_struct * SCM;

/* Smob print hook for uniform vectors.  */
int uvec_print (SCM);
int
uvec_print (SCM  uvec)
{
  union {
    uint8_t *u8;
    int8_t *s8;
    uint16_t *u16;
    int16_t *s16;
    uint32_t *u32;
  } np;
  size_t i = 0;
  const size_t uvlen = 10;
  void *uptr = NULL;

  switch (SCM_UNPACK ((((struct scm_unused_struct * *)((int *) (SCM_UNPACK (uvec)))) [1])))
  {
    case 0: np.u8 = (uint8_t *) uptr; break;
    case 1: np.s8 = (int8_t *) uptr; break;
    case 2: np.u16 = (uint16_t *) uptr; break;
    case 3: np.s16 = (int16_t *) uptr; break;
    case 4: np.u32 = (uint32_t *) uptr; break;
    default:
      abort ();			/* Sanity check.  */
      break;
  }

  while (i < uvlen)
    {
      i = (int) *np.u8; np.u8++;
    }

  return 1;
}

int main()
{
  uvec_print(NULL);
  return 0;
}

/* Local variables: */
/* compile-command: "gcc -g -O2 -Wall -Wmissing-prototypes -S njtest.c" */
/* End: */

Re: GNU Guile 1.8.4 released

[Kamaraju S Kusumanchi]

<posted & mailed>

Neil Jerram wrote:

> For the record, and future searchers, this appears to be a GCC bug in
> GCC version 3.4.2.  Given the attached program (which is cut down from
> uvec_print in srfi-4.c), GCC 3.4.2 gives:
> 

Thanks for looking into this. I do not know if it is obvious from the logs
but just want to mention that gcc 4.2.3 was used when building the Debian
packages.

raju
-- 
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/