Re: GNU Guile 1.9.11 released (beta)

[Taylor Venable <taylor@metasyntax.net>]

On Fri, Jun 11, 2010 at 6:23 PM, Taylor Venable <taylor@metasyntax.net> wrote:
> On Tue, Jun 1, 2010 at 5:57 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> We are pleased to announce GNU Guile release 1.9.11.  This may be the
>> last pre-release before the 2.0 release.
>
> During the configure process, the script produces errors in the shell:
>
> ./configure: line 20215: test: -lt: unary operator expected
> ./configure: line 20216: test: -eq: unary operator expected
> ./configure: line 20252: test: -lt: unary operator expected
> ./configure: line 20253: test: -eq: unary operator expected
> ./configure: line 20306: test: -lt: unary operator expected
> ./configure: line 20307: test: -eq: unary operator expected
> ./configure: line 20360: test: -lt: unary operator expected
> ./configure: line 20361: test: -eq: unary operator expected
> ./configure: line 20397: test: -lt: unary operator expected
> ./configure: line 20398: test: -eq: unary operator expected
> ./configure: line 20441: test: -lt: unary operator expected
> ./configure: line 20442: test: -eq: unary operator expected
> ./configure: line 20488: test: -lt: unary operator expected
> ./configure: line 20489: test: -eq: unary operator expected

I did a little more research on this today; it happens with the three
most recent versions of libunistring (0.9.2 ; 0.9.2.1 ; 0.9.3), and
the reason it doesn't occur in Guile 1.9.10 is because the configure
script there doesn't use the gnulib libunistring modules (where the
errors appear) to check the installed libunistring version
(specifically, from file m4/libunistring-base.m4[1]).

With some deeper probing (quite ... enlightening ... work - I've never
really examined how configure scripts are written before) I think I've
identified the origin of the problem.  On line 12165, if
HAVE_LIBUNISTRING is yes then the version number is extracted into
major/minor/subminor components.  However, HAVE_LIBUNISTRING isn't set
to yes or no until at the earliest line 15115, and the version itself
isn't extracted from the header file until line 16197 I think, so the
version components are always unset.  The version checking code
assumes that if HAVE_LIBUNISTRING is yes then the version components
have been extracted, but with the ordering in the configure file this
seems impossible: the version components will always be unset and
HAVE_LIBUNISTRING may be either yes or no.  It seems that a fix for
this problem is to move that version extraction code (starting at
12165) down in the file so that it appears after LIBUNISTRING_VERSION
has been set (for example, down near line 16280).  Doing this in the
configure script itself causes success, but I don't really know how
that script is generated, so hopefully this is enough information to
help the developers get the "right" solution.

[1] http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring-base.m4

Best regards,

-- 
Taylor C. Venable
http://metasyntax.net/