GNOME Bugzilla – Bug 708673
config.status: error: po/Makefile.in.in was not created by intltoolize.
Last modified: 2013-09-29 21:15:44 UTC
Created attachment 255618 [details] gnome-autogen.sh 3.10 log When running gnome-autogen.sh from gnome-common 3.10 on a project the resulting ./configure fails with the following error message: config.status: error: po/Makefile.in.in was not created by intltoolize. (complete log attached) With gnome-autogen.sh 3.7.4 the build system is created properly and I can successfully run ./configure.
In comparison, I've also attached a log from gnome-autogen.sh 3.7.4
Created attachment 255619 [details] gnome-autogen.sh 3.7.4 log
configure output is useless; what we need is the config.log file. Also, exactly which project is this (link to git repo) and which version thereof?
As gnome-common now uses autoreconf, intltool and gettext macros cannot be used in configure.ac simultaneously, as the gettext Makefile.in.in clobbers the one copied by intltoolize. The intltool documentation was changed a while ago to only mention IT_PROG_INTLTOOL: https://code.launchpad.net/~robert-ancell/intltool/remove-am-gnu-gettext/+merge/114274 Projects using gnome-autogen.sh with intltool should follow the intltool documentation, and only use IT_PROG_INTLTOOL in configure.ac.
(In reply to comment #3) > configure output is useless; what we need is the config.log file. Also, exactly > which project is this (link to git repo) and which version thereof? libpeas 1.8.1, libosinfo 0.2.7 or xchat-gnome are one of the packages which I noticed which now fails to build with gnome-common 3.10
libpeas was fixed after 1.9.0 was released (bug 706835), so there should probably be a new release. libosinfo was fixed, with the fix being in the released 0.2.8. xchat-gnome has not had a release in several years, so the GETTEXT macros in configure.ac should be removed if it is to work with the latest gnome-common.
How does a gnome-common change affect a released tarball, btw? It shouldn't. Also unfortunately xchat-gnome git isnt' in a releasable state…
(In reply to comment #7) > How does a gnome-common change affect a released tarball, btw? It shouldn't. The libosinfo Debian package runs autogen.sh, which in turn runs gnome-autogen.sh: http://anonscm.debian.org/gitweb/?p=pkg-libvirt/libosinfo.git;a=blob;f=debian/rules;h=154bcf086c3c339814dddb1c9cf1b68becc7d2b5;hb=HEAD The libpeas package looks like it does something similar (at least gnome-autogen.sh is mentioned in debian/rules): http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/libpeas/debian/rules?revision=37923&view=markup
I've filed bugs against the affected packages in Debian (it turned out that not too many were affected). While it would have been nice if gnome-autogen.sh wouldn't break backwards compatibility, I can understand the switch to use autoreconf has its advantages. So feel free to close the bug report.