Summary: | app-emulation/libguestfs - checking if pod2man takes --stderr option... /// .../work/libguestfs-1.18.2/configure: line 47892: syntax error near unexpected token `;;' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jared B. <nitro> |
Component: | Current packages | Assignee: | Andreis Vinogradovs ( slepnoga ) <andreis.vinogradovs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | brot+gentoo, c.affolter, himbeere, ibuyandtrade0+bugs.gentoo.org, maksbotan, rich |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
config.log
configure.xz A fixed patch file Another patchfile which prevent using of env.d (suggestion) |
Description
Jared B.
2012-07-24 04:07:43 UTC
Does portage re-run 'autoconf'? Line 47892 doesn't make any sense if it means the ./configure script supplied in the libguestfs 1.18.2 tarball. The (upstream) test seems OK, so my only thought is that you've got an old version of autoconf that produces a corrupt configure script. Perhaps we are using a macro that your autoconf doesn't support? Sorry, not a lot to go on. Three suggestions: - Try newer libguestfs (1.18.5 is newest stable) - Try updating autoconf - Find out what is in the generated ./configure script around the line that generates the error. (In reply to comment #1) Thanks for the suggestions. Unfortunately, I still haven't had much luck: > - Try newer libguestfs (1.18.5 is newest stable) Done, by renaming the existing 1.18.2 ebuild to 1.18.5. Still fails the same way. > - Try updating autoconf This is a brand new server install, with autoconf 2.68 (default) and 2.13 (for nspr). It looks like it was written specifically for 2.68, so I don't think an old version would be the problem: m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],, > - Find out what is in the generated ./configure > script around the line that generates the error. I agree it doesn't make a whole lot of sense. I've attached the file from the build directory, just in case it's regenerating it like you suggested. Maybe that'd give you more info to work with? Don't know. Like I said before, this configure script is a mess. Created attachment 319168 [details]
configure.xz
Thanks for attaching the configure script. It has certainly been miscompiled by autoconf for some reason. Here is the code which fails: ---------------------------------------- for ac_prog in genisoimage mkisofs do # Extract the first word of \"$ac_prog\", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 { $as_echo \"$as_me:${as_lineno-$LINENO}: checking for $ac_word\" >&5 $as_echo_n \"checking for $ac_word... \" >&6; } if ${ac_cv_path_GENISOIMAGE+:} false; then : $as_echo_n \"(cached) \" >&6 else case $GENISOIMAGE in \\/* | ?:\\/*" >&6; } ac_cv_path_GENISOIMAGE="$GENISOIMAGE" # Let the user override the test with a path. ;; ###### line 47892 *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR for as_dir in $PATH$PATH_SEPARATOR/usr/sbin$PATH_SEPARATOR/sbin do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then ac_cv_path_GENISOIMAGE="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 fi done done IFS=$as_save_IFS ;; esac fi GENISOIMAGE=$ac_cv_path_GENISOIMAGE if test -n "$GENISOIMAGE"; then { $as_echo "$as_me:${as_lineno-$LINENO}: result: $GENISOIMAGE" >&5 $as_echo "$GENISOIMAGE" >&6; } else { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 $as_echo "no" >&6; } fi ----------------------------- The whole section before line 47892 is corrupted in a number of ways compared to the configure script supplied in the upstream tarball: - double quotes have been escaped \" - [ and ] characters have been omitted - } is used instead of ) in case statements - >&6; appears in a bogus place - unclosed " Something has really gone wrong with the way this configure script is generated, and the obvious culprit is autoconf. I think this is some sort of gross bug in autoconf (or m4?). By the way, in what file did you see this line? m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],, It's not in any configure.ac that we supply, and bare m4 directives shouldn't appear in the configure script. (In reply to comment #5) > By the way, in what file did you see this line? > m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],, aclocal.m4, in the work directory. Just happened to see it while poking around, and figured I'd mention it since you had brought up the possibility of it being an autoconf version issue. No idea if it's actually relavant or not. :-) aclocal.m4 is generated by aclocal (from automake) and m4/* ahh, ok. I guess the version number was tagged on then to show what generated it, not necessarily what it was designed for. Either wya, I'm still at a loss. :-) I confirm the bug. The problem comes from a bad patch file. files/0002-configure_ac_automagic.patch: @@ -442,7 +450,7 @@ AC_MSG_RESULT([yes]) POD2_STDERR_OPTION="--stderr" else - AC_MSG_RESULT([no]) + AC_MSG_RESULT([no] POD2_STDERR_OPTION="" fi This patch section is only a bug, removing one ')'. removing this section will fix problem. Created attachment 320550 [details]
A fixed patch file
Patch file generated against libguestfs-1.18.5.
I also added a missing LT_INIT, and a subir for examples files.
Created attachment 320554 [details, diff]
Another patchfile which prevent using of env.d (suggestion)
As we deal with the patchfile i suggest to remove env file and patch src/Makefile.am.
Remove files/env.file and in ebuild file, line
newenvd "${FILESDIR}"/env.file 99"${PN}"
(In reply to comment #9) > I confirm the bug. > > The problem comes from a bad patch file. > files/0002-configure_ac_automagic.patch: > @@ -442,7 +450,7 @@ > AC_MSG_RESULT([yes]) > POD2_STDERR_OPTION="--stderr" > else > - AC_MSG_RESULT([no]) > + AC_MSG_RESULT([no] > POD2_STDERR_OPTION="" > fi > > This patch section is only a bug, removing one ')'. > removing this section will fix problem. Just a note that in libguestfs 1.18.6 (which is only in git now, but the tarball will be uploaded in a few days) the whole way that POD is done has changed. This hunk will be redundant. I'll have a look at the other patch and see what can go upstream. My quote is not a fix, but it's the faulty hunk of the portage files/0002-configure_ac_automagic.patch. The whole hunk must be removed, there will be no problem if POD will change in 1.18.6. This hunk only delete a ')' which make autotools fail. I still have this issue with all versions in portage and 19.1 in overlay. checking if pod2man takes --stderr option... /var/tmp/notmpfs/portage/app-emulation/libguestfs-1.19.1/work/libguestfs-1.19.1/configure: line 46975: syntax error near unexpected token `;;' /var/tmp/notmpfs/portage/app-emulation/libguestfs-1.19.1/work/libguestfs-1.19.1/configure: line 46975: ` ;;' *** Bug 435214 has been marked as a duplicate of this bug. *** Fixed in 1.18.9 by upstream, old versions cleaned. |