On Fri, Jun 11, 2010 at 6:23 PM, Taylor Venable <[email protected]> wrote: > On Tue, Jun 1, 2010 at 5:57 PM, Ludovic Courtès <[email protected]> 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/
