guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel

[Ludovic Courtès]

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On 10/19/2011 11:49 PM, Ludovic Courtès wrote:
>
>> I’ve reproduced it on armv5tel-unknown-linux-gnueabi, with Guile 1.8.8,
>> GCC 4.5.1, and glibc 2.12.
>> The 0x1 above seems to be the value of some port’s ‘putback_buf’ field.
>> Normally it should be either NULL or a valid pointer.
>> Adding ‘c_port->putback_buf = NULL’ in
>> $GNUTLS/guile/src/core.c:make_session_record_port, which is supposed to
>> be a non-functional change, leads to a malloc inconsistency much more
>> quickly (setting $MALLOC_CHECK_=2 helps catch it.)
>> So I’m starting to wonder if libguile and GnuTLS somehow have a
>> different vision of the layout of ‘scm_t_port’, which would explain
>> these inconsistencies.
>
> Hi,
>  Any update on that? Do the observed issue seem related to a gnulib change?

Yes.

The problem is that Guile 1.8 uses off_t fields in its scm_t_port
structure, which is public [0].  On armv5tel-unknown-linux-gnueabi, that
structure is 96-byte long when _FILE_OFFSET_BITS == 32, and 120-bit long
otherwise.

By default, Guile 1.8 is compiled with _FILE_OFFSET_BITS == 32, whereas
GnuTLS 3.0 gets compiled with _FILE_OFFSET_BITS == 64 (probably as a
result of a Gnulib change.)  Hence the problem.

A simple workaround is to build Guile 1.8 with
CPPFLAGS=-D_FILE_OFFSET_BITS=64, or to #define _FILE_OFFSET_BITS 32 just
before any #include <libguile.h> in GnuTLS (or, better yet, to use Guile
2.0 ;-)).

Ideally, though, GnuTLS would have a configure check to determine what
_FILE_OFFSET_BITS value Guile is expecting, but I can’t think of any
reliable way to do that.  Ideas?

Thanks,
Ludo’.

[0] Guile 2.0 uses scm_t_off, instead of off_t, precisely to avoid this
    problem.