Guile HEAD on Cygwin-1.7

Guile HEAD on Cygwin-1.7

[szgyg]

-*- outline -*-

Guile HEAD on the upcoming Cygwin-1.7 [1]

Good news first: I can't reproduce the infamous "threaded Guile hangs on 
quit" error. (Cygwin has been shipping single-threaded Guile up to now.)

Guile builds with only minor hiccups. I hope these can be fixed before 
the prerelease.

make check shows serious problems. I will investigate further.

s

[1] http://cygwin.com/ml/cygwin/2009-06/msg00346.html


* make

** configure and make with the same set of flags

Configuration test passes, make fails. Yes, -Werror.

cc1: warnings being treated as errors
../../libguile/gen-scmconfig.c: In function 'main':
../../libguile/gen-scmconfig.c:427: error: visibility attribute not 
supported in this configuration; ignored
make[2]: *** [gen-scmconfig.o] Error 1


** pass -no-undefined when linking libguile_i18n

Other libs already have this.


** split the #ifdef in libguile/i18n.c line 59

Cygwin has langinfo.h, but not nl_types.h


** wrong path when compiling psyntax-pp.scm

First time only

Making all in module
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
/home/szgyg/src/GIT/guile/=build/meta/guile --no-autocompile -s 
../../module/ice-9/compile-psyntax.scm \
                 ../../module/ice-9/psyntax.scm 
../../module/ice-9/psyntax-pp.scm
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
"ice-9/psyntax-pp.go" "ice-9/psyntax-pp.scm"
ERROR: In procedure open-file:
ERROR: No such file or directory: "ice-9/psyntax-pp.scm"
make[2]: *** [ice-9/psyntax-pp.go] Error 1

Subsequent makes use the correct path:

Making all in module
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
"ice-9/psyntax-pp.go" "../../module/ice-9/psyntax-pp.scm"
wrote `ice-9/psyntax-pp.go'


** readline is required, not optional

GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
"ice-9/lineio.go" "../../module/ice-9/lineio.scm"
ERROR: readline is not provided in this Guile installation
make[2]: *** [ice-9/lineio.go] Error 1


* make check

** -Werror again

cc1: warnings being treated as errors
../../../test-suite/standalone/test-unwind.c: In function 'check_ports':
../../../test-suite/standalone/test-unwind.c:213: error: call to 
'mktemp' declared with attribute warning: the use of `mktemp' is 
dangerous; use `mkstemp' instead
make[4]: *** [test_unwind-test-unwind.o] Error 1


** stack overflow

I didn't dive into this yet. Any hint?

make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
make  check-TESTS
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-autocompile argument to disable.
;;; compiling /home/szgyg/src/GIT/guile/test-suite/lib.scm
;;; compiled 
/home/szgyg/.guile-ccache/1.9//home/szgyg/src/GIT/guile/test-suite/lib.scm.go
ERROR: Stack overflow
Running alist.test
[...]


** segfault

On one occasion I got

make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
make  check-TESTS
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
/bin/sh: line 5:  3944 Segmentation fault      (core dumped) ${dir}$tst
FAIL: check-guile

Re: Guile HEAD on Cygwin-1.7

[Andy Wingo]

On Thu 18 Jun 2009 09:33, szgyg <szgyg@ludens.elte.hu> writes:

> ** wrong path when compiling psyntax-pp.scm
>
> First time only
>
> Making all in module
> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
> /home/szgyg/src/GIT/guile/=build/meta/guile --no-autocompile -s 
> ../../module/ice-9/compile-psyntax.scm \
>                 ../../module/ice-9/psyntax.scm
> ../../module/ice-9/psyntax-pp.scm
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
> "ice-9/psyntax-pp.go" "ice-9/psyntax-pp.scm"
> ERROR: In procedure open-file:
> ERROR: No such file or directory: "ice-9/psyntax-pp.scm"
> make[2]: *** [ice-9/psyntax-pp.go] Error 1
>
> Subsequent makes use the correct path:
>
> Making all in module
> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
> "ice-9/psyntax-pp.go" "../../module/ice-9/psyntax-pp.scm"
> wrote `ice-9/psyntax-pp.go'

I wonder why it's regenerating psyntax-pp.scm. It shouldn't, psyntax.scm
should be newer than psyntax-pp.scm. Can you make a fresh checkout and
try again? It could have been an accidental change from the copyright
updating.

> ** readline is required, not optional
>
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
> "ice-9/lineio.go" "../../module/ice-9/lineio.scm"
> ERROR: readline is not provided in this Guile installation

Yes this is a problem. Guile shouldn't depend on readline at all, not
even in Scheme modules that are not loaded by default. We should move
this module to guile-readline, IMO, or work out some other solution.

> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
> make  check-TESTS
> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
> ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-autocompile argument to disable.
> ;;; compiling /home/szgyg/src/GIT/guile/test-suite/lib.scm
> ;;; compiled
> /home/szgyg/.guile-ccache/1.9//home/szgyg/src/GIT/guile/test-suite/lib.scm.go
> ERROR: Stack overflow
> Running alist.test
> [...]

What revision of the git repo was this?

> On one occasion I got
>
> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
> make  check-TESTS
> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
> /bin/sh: line 5:  3944 Segmentation fault      (core dumped) ${dir}$tst
> FAIL: check-guile

To me that looks like a segfault in your shell.

Thanks for the report,

Andy
-- 
http://wingolog.org/

Re: Guile HEAD on Cygwin-1.7

[szgyg]

Andy Wingo wrote:
> On Thu 18 Jun 2009 09:33, szgyg writes:
> 
>> ** wrong path when compiling psyntax-pp.scm
>>
>> First time only
>>
>> Making all in module
>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
>> /home/szgyg/src/GIT/guile/=build/meta/guile --no-autocompile -s 
>> ../../module/ice-9/compile-psyntax.scm \
>>                 ../../module/ice-9/psyntax.scm
>> ../../module/ice-9/psyntax-pp.scm
>> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
>> "ice-9/psyntax-pp.go" "ice-9/psyntax-pp.scm"
>> ERROR: In procedure open-file:
>> ERROR: No such file or directory: "ice-9/psyntax-pp.scm"
>> make[2]: *** [ice-9/psyntax-pp.go] Error 1
>>
>> Subsequent makes use the correct path:
>>
>> Making all in module
>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
>> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
>> "ice-9/psyntax-pp.go" "../../module/ice-9/psyntax-pp.scm"
>> wrote `ice-9/psyntax-pp.go'
> 
> I wonder why it's regenerating psyntax-pp.scm. It shouldn't, psyntax.scm
> should be newer than psyntax-pp.scm.

Git doesn't preserve timestamps, so either file can be the newer after a
fresh checkout.

>> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>> make  check-TESTS
>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
>> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
>> ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
>> ;;;       or pass the --no-autocompile argument to disable.
>> ;;; compiling /home/szgyg/src/GIT/guile/test-suite/lib.scm
>> ;;; compiled
>> /home/szgyg/.guile-ccache/1.9//home/szgyg/src/GIT/guile/test-suite/lib.scm.go
>> ERROR: Stack overflow
>> Running alist.test
>> [...]
> 
> What revision of the git repo was this?

Sorry, the fact that the testing framework catches other errors, but not
stack overflow, tricked me. The stack overflow was in elisp.test.

--- T.scm ---
(define *old-stack-level* (and=> (memq 'stack (debug-options)) cadr))
(debug-set! stack (* 2 *old-stack-level*))
(display #t)
-------------

$ guile -q --debug -s T.scm

Backtrace:
In ../../module/ice-9/boot-9.scm:
  874: 0* [#<program 100d7500 ()>]
In unknown file:
    ?: 1* [primitive-load "T.scm"]
In ../../module/ice-9/psyntax-pp.scm:
8216: 2* [# #]

ERROR: Stack overflow

in
commit e33779e3b84b4822b4d51562d7c4f1e65408151d
Date:   Thu Jun 25 23:24:57 2009 +0100
     Revert "* FAQ: New file."

The stack can grow a little, but not so much. Works with the factor 1.3, 
but not with 1.4 (*old-stack-level* is  416784).

>> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>> make  check-TESTS
>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
>> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
>> /bin/sh: line 5:  3944 Segmentation fault      (core dumped) ${dir}$tst
>> FAIL: check-guile
> 
> To me that looks like a segfault in your shell.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3544.0xc1c]
0x6aac70d9 in scm_read_delimited_x (delims=0x100e6400, str=0x102f90a0,
     gobble=0x104, port=0x102bd398, start=0x204, end=0x204)
     at ../../libguile/inline.h:307
307           if (scm_fill_input (port) == EOF)
(gdb) set language scheme
Warning: the current language does not match this frame.
(gdb) frame
#0  0x6aac70d9 in scm_read_delimited_x (delims="\x0c",
 
str="??\x1da??\x1daP},\x10p?+\x10??5\x10?\x00\x00\x00\x80?&\x101?\x1daEy,\x1
0\x88y,\x10AA3\x10\x81\x00\x00\x00??\x1da??\x1daAx,\x10p?+\x10h3\x15\x10i\x00\x0
0\x00c?:\x10\x8c?\x1da?w,\x10\x90w,\x10\x00\x00\x00\x00Q\x00\x00\x00h/\x15\x10",
  gobble=#t,
     port=#<input: /usr/local/share/guile/1.9/guile-procedures.txt 70>,
     start=#<undefined>, end=#<undefined>) at ../../libguile/inline.h:307
307           if (scm_fill_input (port) == EOF)
(gdb) set language c
(gdb) p *((scm_t_port *)((SCM *)0x102bd398)[1])
$1 = {port = 0x102bd398, revealed = 0, stream = 271938816,
   file_name = 0x100e64e0, line_number = 0, column_number = 0,
   read_buf = 0x103c6300 "This is guile-procedures.txt, produced by 
makeinfo vers
ion 4.13 from\nguile-procedures.texi.\n\n\facons\n\n -- Scheme 
Procedure: acons
key value alist\n     Add a new key-value pair to ALIST.  A new pair is 
"...,
   read_pos = 0x103c6300 "This is guile-procedures.txt, produced by 
makeinfo vers
ion 4.13 from\nguile-procedures.texi.\n\n\facons\n\n -- Scheme 
Procedure: acons
key value alist\n     Add a new key-value pair to ALIST.  A new pair is 
"...,
   read_end = 0x103d6300 "\004\004", read_buf_size = 65536,
   saved_read_buf = 0x0, saved_read_pos = 0x0, saved_read_end = 0x0,
   saved_read_buf_size = 0, write_buf = 0x10364ca0 "",
   write_pos = 0x10364ca0 "", write_end = 0x10364ca1 "", write_buf_size = 1,
   shortbuf = 0 '\0', rw_random = 1, rw_active = SCM_PORT_READ,
   putback_buf = 0x0, putback_buf_size = 0}
(gdb) p ((((scm_t_bits)(((SCM*)0x102bd398)[0]))>>8)&0x0ff)
$3 = 0
(gdb)  p scm_ptobs[((((scm_t_bits)(((SCM*)0x102bd398)[0]))>>8)&0x0ff)]
$5 = {name = 0x6ab1d120 "file", mark = 0, free = 0x6aa9e6c1 <fport_free>,
   print = 0x6aa9f181 <fport_print>, equalp = 0,
   close = 0x6aa9e5dc <fport_close>, write = 0x6aa9e804 <fport_write>,
   flush = 0x6aa9e48e <fport_flush>, end_input = 0x6aa9e3c2 
<fport_end_input>,
   fill_input = 0x6aa9e928 <fport_fill_input>,
   input_waiting = 0x6aa9e2dc <fport_input_waiting>,
   seek = 0x6aa9e6d6 <fport_seek_or_seek64>,
   truncate = 0x6aa9e38a <fport_truncate>}

I can trigger this through another path, too:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2728.0x708]
0x6aaca212 in flush_ws (port=0x10137360, eoferr=0x0)
     at ../../libguile/inline.h:307
307           if (scm_fill_input (port) == EOF)

I don't see any obvious error. Any hint?

> Thanks for the report,

Thanks to take care of the report,

s

Re: Guile HEAD on Cygwin-1.7

[Andy Wingo]

Hi szgyg,

On Sat 27 Jun 2009 15:36, szgyg <szgyg@ludens.elte.hu> writes:

> Andy Wingo wrote:
>> On Thu 18 Jun 2009 09:33, szgyg writes:
>>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
>>> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
>>> "ice-9/psyntax-pp.go" "../../module/ice-9/psyntax-pp.scm"
>>> wrote `ice-9/psyntax-pp.go'
>>
>> I wonder why it's regenerating psyntax-pp.scm. It shouldn't, psyntax.scm
>> should be newer than psyntax-pp.scm.
>
> Git doesn't preserve timestamps, so either file can be the newer after a
> fresh checkout.

Ah, I didn't know this. Hmm, this is a problem. Perhaps we need some
auxiliary Makefile help to make sure psyntax-pp is seen as fresh after a
fresh checkout.

> --- T.scm ---
> (define *old-stack-level* (and=> (memq 'stack (debug-options)) cadr))
> (debug-set! stack (* 2 *old-stack-level*))
> (display #t)
> -------------
>
> $ guile -q --debug -s T.scm
>
> Backtrace:
> In ../../module/ice-9/boot-9.scm:
>  874: 0* [#<program 100d7500 ()>]
> In unknown file:
>    ?: 1* [primitive-load "T.scm"]
> In ../../module/ice-9/psyntax-pp.scm:
> 8216: 2* [# #]
>
> ERROR: Stack overflow

Interesting. Is this the full backtrace? What were your CFLAGS when
compiling Guile?

> in
> commit e33779e3b84b4822b4d51562d7c4f1e65408151d
> Date:   Thu Jun 25 23:24:57 2009 +0100
>     Revert "* FAQ: New file."
>
> The stack can grow a little, but not so much. Works with the factor 1.3,
> but not with 1.4 (*old-stack-level* is  416784).

I don't understand -- do you mean to say that T.scm works if "(* 2" is
replaced with "(* 1.3"?

>>> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>>> make  check-TESTS
>>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>>> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
>>> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
>>> /bin/sh: line 5:  3944 Segmentation fault      (core dumped) ${dir}$tst
>>> FAIL: check-guile
>>
>> To me that looks like a segfault in your shell.

Hmm, I guess not ;-)

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 3544.0xc1c]
> 0x6aac70d9 in scm_read_delimited_x (delims=0x100e6400, str=0x102f90a0,
>     gobble=0x104, port=0x102bd398, start=0x204, end=0x204)
>     at ../../libguile/inline.h:307
> 307           if (scm_fill_input (port) == EOF)

What exactly is segfaulting here? All of the vars look fine, and in your
printouts. This seems just to be a problem running Guile, perhaps not
specific to the tests. Can you run meta/guile and it works? If not,
meta/gdb-uninstalled-guile might be useful.

Andy
-- 
http://wingolog.org/

Re: Guile HEAD on Cygwin-1.7

[szgyg]

Andy Wingo wrote:
> On Sat 27 Jun 2009 15:36, szgyg writes:
>> --- T.scm ---
>> (define *old-stack-level* (and=> (memq 'stack (debug-options)) cadr))
>> (debug-set! stack (* 2 *old-stack-level*))
>> (display #t)
>> -------------
>>
>> $ guile -q --debug -s T.scm
>>
>> Backtrace:
>> In ../../module/ice-9/boot-9.scm:
>>  874: 0* [#<program 100d7500 ()>]
>> In unknown file:
>>    ?: 1* [primitive-load "T.scm"]
>> In ../../module/ice-9/psyntax-pp.scm:
>> 8216: 2* [# #]
>>
>> ERROR: Stack overflow
> 
> Interesting. Is this the full backtrace?

Yes.

> What were your CFLAGS when
> compiling Guile?

My CFLAGS is empty, configure sets to -g -O2.

>> The stack can grow a little, but not so much. Works with the factor 1.3,
>> but not with 1.4 (*old-stack-level* is  416784).
> 
> I don't understand -- do you mean to say that T.scm works if "(* 2" is
> replaced with "(* 1.3"?

Yes, with "(inexact->exact (floor (* 1.3".

-----

>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to thread 3544.0xc1c]
>> 0x6aac70d9 in scm_read_delimited_x (delims=0x100e6400, str=0x102f90a0,
>>     gobble=0x104, port=0x102bd398, start=0x204, end=0x204)
>>     at ../../libguile/inline.h:307
>> 307           if (scm_fill_input (port) == EOF)
> 
> What exactly is segfaulting here? All of the vars look fine, and in your
> printouts.
> This seems just to be a problem running Guile, perhaps not
> specific to the tests. Can you run meta/guile and it works? If not,
> meta/gdb-uninstalled-guile might be useful.

Thanks, `./check-guile -i meta/gdb-uninstalled-guile foo.test' is pretty 
cool.

That segfault was an fd_set overflow. We should
#define FD_SETSIZE 1024
before including sys/types.h on cygwin. Also, guile should check that 
  (filedescriptor < FD_SETSIZE) before FD_SET and select.

s

Re: Guile HEAD on Cygwin-1.7

[Andy Wingo]

Hi szgyg,

I can't recall where we were with this.

1. psyntax-pp.scm sometimes regenerating itself

2. some kind of segfault related to stack sizes on cygwin

3. The following:

On Tue 07 Jul 2009 17:53, szgyg <szgyg@ludens.elte.hu> writes:

> That segfault was an fd_set overflow. We should
> #define FD_SETSIZE 1024
> before including sys/types.h on cygwin. Also, guile should check that
> (filedescriptor < FD_SETSIZE) before FD_SET and select.

Is that correct?

Andy
-- 
http://wingolog.org/

Re: Guile HEAD on Cygwin-1.7

[szgyg]

Andy Wingo wrote:
> 1. psyntax-pp.scm sometimes regenerating itself

Yes.

> 2. some kind of segfault related to stack sizes on cygwin

Not segfault, stack overflow after we make the stack bigger with
debug-set!. I didn't debugged this yet.

> 3. The following:
> 
>> That segfault was an fd_set overflow. We should
>> #define FD_SETSIZE 1024
>> before including sys/types.h on cygwin. Also, guile should check that
>> (filedescriptor < FD_SETSIZE) before FD_SET and select.

Yes.

4. Split the #ifdef in libguile/i18n.c (line 63): there we should 
include langinfo.h, but cygwin doesn't have nl_types.h.

5. Parameters in libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS is 
wrong (libguile/Makefile.am line 135). Please copy from other .so's 
LD_FLAGS, as the others build fine.

6. Build tries to compile ice-9/lineio.scm, but fails without readline.

Thanks,
  s

Merging libguile-i18n with libguile

[Ludovic Courtès]

Hi,

szgyg <szgyg@ludens.elte.hu> writes:

> 5. Parameters in libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS is
> wrong (libguile/Makefile.am line 135). Please copy from other .so's
> LD_FLAGS, as the others build fine.

I've seen this report before, but FWIW, I've been thinking about merging
libguile-i18n into libguile.  I created it as a separate library long
ago, but I'm not so sure the library size justifies it (on
x86_64-linux-gnu, `.text' is 35 KiB, which is 19% of the 649 KiB of
current libguile's `.text').

What do you think?

Thanks,
Ludo'.

Re: Merging libguile-i18n with libguile

[Andy Wingo]

On Sun 26 Jul 2009 15:12, ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> szgyg <szgyg@ludens.elte.hu> writes:
>
>> 5. Parameters in libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS is
>> wrong (libguile/Makefile.am line 135). Please copy from other .so's
>> LD_FLAGS, as the others build fine.
>
> I've seen this report before, but FWIW, I've been thinking about merging
> libguile-i18n into libguile.  I created it as a separate library long
> ago, but I'm not so sure the library size justifies it (on
> x86_64-linux-gnu, `.text' is 35 KiB, which is 19% of the 649 KiB of
> current libguile's `.text').
>
> What do you think?

FWIW, I think this is a good idea.

Andy
-- 
http://wingolog.org/

Re: Merging libguile-i18n with libguile

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> szgyg <szgyg@ludens.elte.hu> writes:
>
>> 5. Parameters in libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS is
>> wrong (libguile/Makefile.am line 135). Please copy from other .so's
>> LD_FLAGS, as the others build fine.
>
> I've seen this report before, but FWIW, I've been thinking about merging
> libguile-i18n into libguile.  I created it as a separate library long
> ago, but I'm not so sure the library size justifies it (on
> x86_64-linux-gnu, `.text' is 35 KiB, which is 19% of the 649 KiB of
> current libguile's `.text').
>
> What do you think?

OK with me.

(I have a vague idea that there should be a future way of building
some smaller subset of libguile, but who knows how we might eventually
do that?)

      Neil