intltool-0.40.5 is stricter, causing a build failure in po/

[Devin Cofer]

I am using fully up to date Arch Linux, with this PKGBUILD (script to make package): http://aur.archlinux.org/packages/awn-agnostic-bzr/awn-agnostic-bzr/PKGBUILD

When compiling, the make fails. Here is the log: http://pastebin.ca/1296787
While in that log I used -march=core2, I also tried -march=x86_64, to no avail.

Thanks.

[Mark Lee (malept)]

Please attach the relevant build log to this bug, instead of using a pastebin. There seems to be a lot of extra text in the pastebin.

[Devin Cofer (ranguvar)]

Here you go, this is the end part.

[Mark Lee (malept)]

What version of gettext do you have installed?

FWIW, I use the agnostic version of Awn (with gettext 0.17) and I have not seen that error.

[Devin Cofer (ranguvar)]

0.17. Just let me know if there's anything I can do to help get this working :) Well, I can't code well (yet). But anything to debug :P

I don't really understand the error - do you know what's happening?

[Mark Lee (malept)]

Not particularly. AFAIK, there's no difference in building between agnostic & gnome when it comes to the gettext-related files.

[Devin Cofer (ranguvar)]

I think I found the problem. Some of the below may actually be unrelated, but...

Here is the full output of the first step, running autogen.sh:

"which: no gnome-autogen.sh in (/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/usr/local/bin:/usr/local/sbin)
/usr/bin/intltoolize
/usr/bin/glib-gettextize
/usr/bin/gtkdocize
/usr/bin/autoreconf
Copying file mkinstalldirs
Copying file po/Makefile.in.in

Please add the files
  codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
  progtest.m4
from the /aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am."

Assuming we continue, './configure --prefix=/usr --sysconfdir=/etc --disable-pymod-checks --with-desktop=agnostic --without-gconf', we get the line "config.status: creating po/Makefile.in" almost all the way down, and then later we hit:

"config.status: executing po/stamp-it commands
config.status: error: po/Makefile.in.in was not created by intltoolize."

Continuing on from there, we hit the already-discussed make error(s).

In the 'po' directory, there is a Makefile, Makefile.in, and Makefile.in.in, all different. Should I upload them?

Could this possibly be related to http://bugs.gentoo.org/show_bug.cgi?id=240958 ?

Thanks.

[Mark Lee (malept)]

Quite possibly. Please downgrade your installed copy of intltool to 0.40.4 to see if it is indeed the same problem.

[Devin Cofer (ranguvar)]

Woot! Downgrading to 0.40.4 solves the problem. The configure no longer gets an error, and the package builds cleanly. Thanks for the help :)

Now, the question is - where's the bug? awn, intltool, or Arch's intltool or awn packages?

[Mark Lee (malept)]

It's an intltool bug.

[Devin Cofer (ranguvar)]

Are you sure? From what I can tell, the patch from 0.40.4 to 0.40.5 only made intltool fail verbosely if po/Makefile.in.in was not created by intltoolize. Packages are having trouble because they don't use intltoolize completely.

http://bugzilla.gnome.org/show_bug.cgi?id=554280

"2008-10-06 Rodney Dawes <email address hidden>
* intltool.m4 (IT_PO_SUBDIR):
Check that Makefile.in came from a Makefile.in.in from intltool"

Just making sure before I file an intltool bug... Arch has a completely vanilla package of it, so that's not the problem either.

Here, I made a patch that fixes the problem:

Is it satisfactory? I know very little about the workings of autogen.sh, intltool... even make, so I may have ruined something. It works fine for me though.

[Mark Lee (malept)]

This patch is a "hack" around the underlying problem. See <http://bugs.gentoo.org/show_bug.cgi?id=242660> for the "correct" solution (which points to specific bug comments). A proper solution will be committed shortly.

[Mark Lee (malept)]

Fix committed in revision 504 of trunk.