[libvirt] boostrap: gzip version check problem on FreeBSD
boostrap.conf lists gzip as build dependency. bootstrap then tries to get it's version number using a get_version() function that executes 'gzio --version' and tries to parse the result. The sed expression expects the version number to contain a dot as gzip outputs it on Linux: $ gzip --version gzip 1.3.12 But on FreeBSD it outputs this: # gzip --version FreeBSD gzip 20100407 Therefore, the sed expression should be relaxed, or bootstrap should not try to parse the version number when it doesn't need it because gzip is listed with '-' as version requirement. Matthias
[adding bug-gnulib] On 11/12/2010 01:24 PM, Matthias Bolte wrote:
boostrap.conf lists gzip as build dependency. bootstrap then tries to get it's version number using a get_version() function that executes 'gzio --version' and tries to parse the result.
The sed expression expects the version number to contain a dot as gzip outputs it on Linux:
$ gzip --version gzip 1.3.12
But on FreeBSD it outputs this:
# gzip --version FreeBSD gzip 20100407
Therefore, the sed expression should be relaxed, or bootstrap should not try to parse the version number when it doesn't need it because gzip is listed with '-' as version requirement.
I'm pushing this to fix the gnulib side of things; a libvirt patch to use the latest gnulib will follow shortly. diff --git i/ChangeLog w/ChangeLog index e348fe2..8a9d7b6 100644 --- i/ChangeLog +++ w/ChangeLog @@ -1,5 +1,11 @@ 2010-11-12 Eric Blake <eblake@redhat.com> + bootstrap: allow FreeBSD gzip + * build-aux/bootstrap (get_version): Parse FreeBSD gzip version, + which has no '.' and goes to stderr. + * build-aux/bootstrap.conf (buildreq): Improve the sample file. + Reported by Matthias Bolte. + maintainer-makefile: check for i18n setup * top/maint.mk (sc_bindtextdomain): Check for evidence that _() will likely work. diff --git i/build-aux/bootstrap w/build-aux/bootstrap index 8c8d777..5278e8e 100755 --- i/build-aux/bootstrap +++ w/build-aux/bootstrap @@ -1,6 +1,6 @@ #! /bin/sh # Print a version string. -scriptversion=2010-10-08.16; # UTC +scriptversion=2010-11-12.20; # UTC # Bootstrap this package from checked-out sources. @@ -345,11 +345,11 @@ get_version() { $app --version 2>&1 | sed -n '# extract version within line - s/.*[v ]\{1,\}\([0-9]\{1,\}\.[.a-z0-9-]*\).*/\1/ + s/.*[v ]\{1,\}\([0-9]\{1,\}\(\.[.a-z0-9-]*\)*\).*/\1/ t done # extract version at start of line - s/^\([0-9]\{1,\}\.[.a-z0-9-]*\).*/\1/ + s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/ t done d diff --git i/build-aux/bootstrap.conf w/build-aux/bootstrap.conf index 75cf6ff..2bb60e2 100644 --- i/build-aux/bootstrap.conf +++ w/build-aux/bootstrap.conf @@ -57,3 +57,11 @@ if test $gettext_external = 1; then m4/xsize.m4 ' fi + +# Build prerequisites +buildreq="\ +autoconf 2.59 +automake 1.9.6 +git 1.5.5 +tar - +" -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On 11/12/2010 02:35 PM, Paul Eggert wrote:
On 11/12/2010 12:50 PM, Eric Blake wrote:
+ s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/
Surely that is a typo. The "*\)\)*" should be a "*\)*\)".
Aargh - I tested on one machine, but committed on another. Typo is now fixed. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Hello, * Eric Blake wrote on Fri, Nov 12, 2010 at 10:40:25PM CET:
On 11/12/2010 02:35 PM, Paul Eggert wrote:
On 11/12/2010 12:50 PM, Eric Blake wrote:
+ s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/
Surely that is a typo. The "*\)\)*" should be a "*\)*\)".
Aargh - I tested on one machine, but committed on another. Typo is now fixed.
But the following limitations from autoconf.info still apply: Nested parentheses in patterns (e.g., `\(\(a*\)b*)\)') are quite portable to current hosts, but was not supported by some ancient `sed' implementations like SVR3. Some `sed' implementations, e.g., Solaris, restrict the special role of the asterisk `*' to one-character regular expressions and back-references, and the special role of interval expressions `\{M\}', `\{M,\}', or `\{M,N\}' to one-character regular expressions. This may lead to unexpected behavior: You can probably ignore the first, but not the second. Cheers, Ralf
participants (4)
-
Eric Blake -
Matthias Bolte -
Paul Eggert -
Ralf Wildenhues