GNOME Bugzilla – Bug 606742
Configure has difficulty detecting bison version
Last modified: 2010-03-06 20:56:27 UTC
I ran into the problem described in https://bugzilla.gnome.org/show_bug.cgi?id=543853 When I checked the upstream fix I noticed that it changed the regex to cut out any non-number characters from the beginning and end of the line: http://cgit.freedesktop.org/gstreamer/common/commit/?id=2c534ab2fc124f94c75d1836eb7f20bd4e71ffc3 On my Fedora 11, Ubuntu 8.04.3, and RHEL4 machines that line does the following: $ /usr/bin/bison --version | head -n 1 | sed 's/^[[^0-9]]*//' | sed 's/[[^0-9]]*$//' | cut -d' ' -f1 bison If I remove the double brackets then it works as expected: $ /usr/bin/bison --version | head -n 1 | sed 's/^[^0-9]*//' | sed 's/[^0-9]*$//' | cut -d' ' -f1 Fedora 11: 2.4.1 RHEL4: 1.875 Ubuntu 8.04.3: 2.3 I assume that no one discovered this because the check following this is: exit ($bison_version < $bison_min_version) ? 0 : 1; and $bison_version == "bison" will always be less than a string starting with a numeral character.
or rather in the latest version of common/m4/gst-parser.m4 the check is: if perl -we "exit ((v$bison_version ge v$bison_min_version) ? 0 : 1)"; then AC_MSG_RESULT([yes]) else AC_MSG_ERROR([no]) fi Which appears to always return a non-error return code (ie. exit(0)) for cases where bison_version == "bison" $ perl -we 'exit (("vbison" ge "v2.4.1") ? 0 : 1)'; echo $? 0
Thanks for reporting, this is fixed now. Same problem was present with the flex version check. commit a2166b7dc235f50f412ef589696392a0a7b7b83f Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Jan 13 09:26:08 2010 +0100 common: Fix flex/bison version checks Before it could (and would) extract the string "bison" as version number because of the double brackets while instead it should really just remove all non-numeric characters. Fixes bug #606742.
Actually no, those double brackets are required because of M4 it seems. Without double brackets it breaks here.
What exactly is the behaviour you get? Please also attach the generated config.log file.
Thanks for the clarification. My apologies, after I sourced the upstream fix from the pre-processed m4 file. I think this bug can be safely closed.