GNOME Bugzilla – Bug 321785
intltool-update in infinite recursion over gstreamer
Last modified: 2012-03-16 12:39:23 UTC
Version details: CVS HEAD 18.11.2005. Distribution/Version: Fedora Core 4 uptodate 18.11.2005. 1. Get latest intltool from gnome cvs, install it. 2. Get latest gstreamer from freedesktop.or cvs cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/gstreamer co gstreamer cd gstreamer/po intltool-update -pot And you get the result: Deep recursion on subroutine "main::SubstituteVariable" at /home/ash/bin/intltool-update line 878, <CONF> line 53757. If I do a strace: strace intltool-update -pot 2> OUT the file OUT grows really big: > 300MB, the process shows no signs of ending and I have to kill the process. I am not attaching the file even bzipped as it is large enough, you may generate it yourself ;-) I get the similar problem using: gst-plugins-base (cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/gstreamer co gst-plugins-base ) Deep recursion on subroutine "main::SubstituteVariable" at /home/ash/bin/intltool-update line 878, <CONF> line 66627. Any ideas? (gettext is 0.14.3-1)
So, gstreamer doesn't use intltool. It doesn't define GETTEXT_PACKAGE in configure.ac, among other things. I'm not immediately sure how to fix this. Once it is fixed though, it will only give you an error. As a workaround, don't use intltool on projects that don't support intltool. :)
*** Bug 323526 has been marked as a duplicate of this bug. ***
Created attachment 59376 [details] [review] recursive-vars-fix.patch This fixes this and similar behaviour where other variables call into themselves: but it's still the problem with introduction of AS_VERSION macro which supposedly sets PACKAGE variable, and we expected AC_INIT stuff to set it (FindPackageName basically did "$varhash[PACKAGE]="$PACKAGE", thus entering infinite loop). Alternative fix is to do similar stuff for AS_VERSION as for AC_INIT if Thomas' macros get really widespread enough. I'd appreciate comment from thomasvs on this, what's his Bugzilla account?
Created attachment 59377 [details] [review] as-version-support.patch This adds support for AS_VERSION macro instead (alternative solution)
Thomas, how commonly used is AS_VERSION, and do you want intltool to support it?
Danilo, this might solve the inifinite recursion, but it doesn't really help overall, as gstreamer doesn't use intltool in the first place, afaict. We should add a check to make sure that the app you're trying to use intltool-update in, supports intltool, I think. GStreamer is doing a lot of overly complicated things with the m4 macros for configure.in. I'm not sure it's a particularly good use case for adding support for. Please go ahead and commit recursive-vars-fix.patch though. Also, your as-version-support.patch seems to be generated from the generated intltool-update script, rather than from intltool-update.in.in. I'm changing the status of this patch to commented-on. I'm still adverse to putting it in, as AS_VERSION is specific to GStreamer.
Comment on attachment 59377 [details] [review] as-version-support.patch It seems to surface in other packages depending on gstreamer: gnome-media does it, and quick Google search (first 10 results uncovers "liboil", "telepathy-sip", "farsight"...), apart from Fluendo stuff. It might be a worthy contender, but a patch would definitely need more work (i.e. define the same variables AS_VERSION does in as-version.m4 so they are subst'ed as well). (as for what is patched, this is easier to test, just patch with -p1 and enter intltool-update.in.in ;)
I am about to change AS_VERSION a little, because in the later releases of autoconf and automake, you're supposed to run AC_INIT with package name and version, instead of from AM_INIT_AUTOMAKE. So it probably makes sense to rework this first and get that done in all projects, before tackling intltool support for it. I'm going to be away for two weeks though, so if it can wait ?
Well, sure, but I only wonder if the AS_VERSION syntax is changing (that's all we are parsing), and are you planning on setting more and/or different variables.
intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009. I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping. Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.