Description of Problem: Generates configure scrits that try to run config.sub ($ac_config_sub) before having defined the $ac_config_sub variable... Version-Release number of selected component (if applicable): 2.13-17 2.53 is also installed in parallel.. automake 1.4 and 1.5 are installed too... I believe I'm using automake1.4 and autoconf2.13 by default... How Reproducible: every time Steps to Reproduce: 1. cvs -d :pserver:anonymous.org:/cvs/gnome checkout gnomeicu 2. cd gnomeicu 3. ./autogen Actual Results: Running ./configure --enable-maintainer-mode --enable-compile-warnings ... loading cache ./config.cache configure: error: can not run Expected Results: Running ./configure --enable-maintainer-mode --enable-compile-warnings ... loading cache ./config.cache (RUN config.sub HERE) Additional Information: It used top work on 7.2.. It works with other distributions (debian woody, etc..)
I can also add that I'm one of the maintainers of gnomeicu... and that it also tried to use $ac_config_guess before defining it... and that just copying the relevant detection code before the use does the job....
Can you please call the auto* commands manually to see which one fails? It may be a temporary issue, but currently I get: | [ensc@kosh gnomeicu]$ aclocal-1.4 -I macros | aclocal: configure.in: 34: macro `AM_PATH_GNET' not found in library which indicates an error in configure.in (AM_PATH_GNET is not documented in automake.info so it is properly a typo).
Created attachment 58905 [details] broken configure script...
missing AM_PATH_GNET probably means that you need libgnet (www.gnetlibrary.org)... Currently all of the auto's run correctly.. The problem is when I run configure I get... Running ./configure --enable-maintainer-mode --enable-compile-warnings ... loading cache ./config.cache configure: error: can not run and there is stops... and this is the line where it is supposed to run $ac_config_sub but $ac_config_sub is defined later.... I've attached an example of broken configure script...
Yes; can reproduce it with a minimal example of ---- AC_INIT(src/gnomeicu.c) AM_INIT_AUTOMAKE(gnomeicu, 0.98.2.7) AM_ICONV AC_OUTPUT() ---- A workaround will be | AC_REQUIRE([AC_LIB_RPATH]) somewhere before the AM_ICONV. Because these iconv-stuff is defined by gettext, it seems to be bad interaction between gettext and autoconf. More recent versions of autoconf do not show the error.
A more general and plain autoconf example is ---- configure.in ----- AC_DEFUN([FOO], [AC_REQUIRE([AC_PROG_INSTALL])]) AC_INIT(X) FOO AC_REQUIRE([AC_CANONICAL_HOST]) AC_OUTPUT([]) ---------
adding AC_REQUIRE([AC_LIB_RPATH]) does make it work... but then po/Makevars is not included in po/Makefile And it does that even if I use autoconf-2.53.... I think that's a gettext bug not autoconf... but.. you may know better than I do...
Please remove the AC_REQUIRE([]) and use the plain AC_LIB_RPATH statement only; AC_REQUIRE should not be used in configure.in... (sorry, when I wrote my comments above it was late and the coffee ran out). You are right; the shipped gettext is borken (e.g. $(top_builddir) in po/Makefile.in.in is undefined, MSGMERGE_UPDATE has a strange definition, intltoolize from intltool-0.18-2 does not work).
Mmmh, I must correct me again... gettext is not guilty. AM_GNOME_GETTEXT is responsible for the missing Makevars. When using 'AM_GNU_GETTEXT' *after* AM_GNOME_GETTEXT the po/Makefile will be genereated correctly
Is there anything that autoconf213 should do to help out here?
adding AC_LIB_RPATH and replacing AM_GNOME_GETTEXT with AM_GNU_GETTEXT in configure.in and adding the intl dir and adding intl to subdirs seems to make it work... But I suppose that would break older gettexts.....?
The "broken" AM_ICONV macro is an autoconf213 issue but I am not sure if gettext-0.11.2 is indented to be used with this old version and what there can be done. Well, somebody can spend energy into tracing the exact reason of the misbehavior, but autoconf-2.13 is old and it would be wasted time IMHO. autoconf-2.13 is the standard autoconf in RH 7.3 because of backward compatibility. IMO, people should use autoconf-2.53 in new projects which can be used in RH by calling 'autoconf-2.53' instead of 'autoconf'. When the GNOME people would make their autogen.sh scripts more general and simple (e.g. the GnomeICU macros/autogen.sh can be replaced entirely with | intltoolize | autoreconf -i (you will need to add 'ACLOCAL_AMFLAGS = -I macros' to Makefile.am also)) then the developer can choose the used autoconf executable by specifying it on the cmdline: | AUTOCONF=autoconf-2.53 ./autogen.sh When using the 'autoreconf' way, advanced automake techniques like 'make distcheck' will be possible which are helping to generate better packages. About AM_GNOME_GETTEXT vs. AM_GNU_GETTEXT: on the first glance, AM_GNOME_GETTEXT *looks* like a rewrite of an elder AM_GNU_GETTEXT. This is bad and preprogrammes brokeness. I do not know enough about Gnome-developing so I can miss important things, but adding some directories manually seems to be a low price for gaining compatibility. If AM_GNU_GETTEXT works for you and the other developers of GnomeICU I would use it instead of the AM_GNOME_GETTEXT variant. The user who compiles GnomeICU and has an older gettext version will not be affected because he does not need to rebuild the build-system.
Ok, I'm deferring this for now.