Hum, it works fine for me, so it's probably dependent on your system setup. 
Since this is error in intltool-build, it's not relevant if it happens in
gnome-panel or now (it will probably fail as well with simple "make check" for you).

It seems as if replacement of @INTLTOOL_ICONV@ in intltool-merge has failed
somehow during make (look at Makefile.am, where this is done).

I don't have much clue into this, but I'd try looking into config.log for where
iconv has been found (if at all).

What this recent intltool should be doing is the following:
- find iconv in your PATH during configure
- use that while producing intltool-merge from intltool-merge.in

I don't know what might be failing on your system, and I'd appreciate if you
find some time to take a look.

Rodney, do you have any idea?

Also, here's the bug where this was introduced (for reference):
http://bugzilla.gnome.org/show_bug.cgi?id=152020

Is this gnome-panel HEAD as well?

Hrmm. It's working fine for me too. I wonder what would break this. I do get
this now, though:

./config.status: line 1: top_builddir: command not found

However, I can't see what is going wrong, since that is not in line 1 of
config.status.

Yeah, gnome-panel HEAD too. But it seems @INTLTOOL_ICONV@ isn't properly
substituted during intltool compilation even though afaict iconv is found properly
I'll try with a clean checkout of intltool.

Talked with Christophe on irc about this. Looks like it is a problem with the
ACLOCAL_FLAGS and having multiple copies of intltool installed (system, and
jhbuild). Marking as NOTABUG. So, this happens because jhbuild intltool gets
run, and the intltool.m4 from the system gets pulled in by aclocal.

*** Bug 155225 has been marked as a duplicate of this bug. ***

Hmm, it should be possible to have multiple intltools installed, right? So it is
indeed a bug and it was just introduced...

Mikael, I think this is a problem of aclocal, and precedence it gives to
ACLOCAL_FLAGS variable: it seems to be evaluated last, instead of first.

It should be perfectly possible to still have more than one version of intltool
installed, as long as right m4 macros are picked up. Perhaps you should try
bootstrapping autoconf as well from within jhbuild, and see if that helps?

(note that I'm just guessing here :)

This was from a clean bootstrap, 

jhbuild bootstrap
jhbuild build

in a clean directory.

Not sure how to handle it but if it's a bug in aclocal the bug wasn't exposed
until some changes made lately, any way they can still be worked around in
intltool (or the changes reverted to hide the issue until it's fixed in aclocal?).

No. It isn't a problem in intltool or aclocal. It's a problem in jhbuild. If you
want jhbuild to work, you need to fix it to re-order flags so that the jhbuild
install dir is preferred over the system dir. If you don't do that, you are
going to have problems with more things than intltool, and I presume you already
have them, but they aren't showing up as publicly.

Hum, everything works fine for me even if I install intltool 0.31.2 in my
default path, and latest intltool in jhbuild path (they have different
intltool.m4's). So, jhbuild still picks up the correct version.

In "jhbuild shell", ACLOCAL_FLAGS is set to single directory (-I
jhbuildroot/share/aclocal), so it's supposed to be correct (that's why I assumed
it might be doing something funky).  One should also be able to add more paths
via .jhbuildrc (see jhbuild/README for how to do that).

I agree that this is neither intltool nor autoconf bug (until proven otherwise :).

I agree that it might not be a bug in intltool or autoconf, but it's a *problem*
for intltool since you changed something to expose this problem. And since
jhbuild is the official way for developers to build GNOME I suggest that this
gets fixed in jhbuild or you'll get a lot of bug reports about it...

Regressing to a buggier state to work around a configuration problem exposed by
a bug fix, seems silly to me. If jhbuild is "the official way" then there needs
to be "an official environment" for which to run jhbuild under, otherwise you
are going to run into problems no matter what. Having ACLOCAL_FLAGS set, so that
it pulls in a system installation over the jhbuild installation, seems broken,
if the jhbuild installation is not the system directory. I'm moving this to the
jhbuild product and reopening. Though, Danilo claims to not be able to reproduce
it, so it may very well just be a problem with something setting ACLOCAL_FLAGS
incorrectly in /etc/profile.d/ or something. I'll let James deal with it though. :)

Ok, I'll remove myself from the CC-line, ciao.

Since this bug seems to have been assigned to me, does anyone have any
information about how to reproduce it?

From a quick look at the gnome-panel source, it is possible that it might
occasionally lose the $ACLOCAL_FLAGS value during a rebuild.  Is that likely to
be the problem?

So no one knows how to reproduce this bug?  If I don't see any activity in the
next week, I'll close this bug report.

If you install intltool using your distro packages and using jhbuild, set
ACLOCAL_FLAGS to "-I /usr/share/aclocal -I $jhbuild_prefix/share/aclocal" and
try to build gnome-panel, I guess you'll get this bug.

Won't that cause you to end up with mismatched versions of intltool.m4 and the
intltool-*.in scripts?

That sounds like a problem with your environment rather than a problem with
intltool or gnome-panel or jhbuild.

Yeah, I know it's a bad setup, but this is how I got bitten by this bug in the
first place. You were asking how to reproduce, so I told you how that happened
to me, I totally understand if you say it's my fault and not jhbuild's ;)

Reassigning back to gnome-panel, since bug 160943 has been fixed.

You can now set up your module so that both the autoconf macros and other
support files are copied in by intltoolize.  This gets rid of problems where the
aclocal search path picks a version of the AC_PROG_INTLTOOL macro that is
incompatible with the intltool-* scripts (as Christophe ran into).

To take advantage of this, you need to do the following:

1) use Automake >= 1.8
2) create an "m4" subdirectory in your project
3) add the following near the top of your configure.in/ac file:
    AC_CONFIG_MACRO_DIR(m4)
4) If you aren't using the gnome-common autogen.sh, change the aclocal
   invocation to this:
    aclocal-X.Y -I m4 $ACLOCAL_FLAGS
5) To make sure rebuilds work right, add an AC_SUBST for ACLOCAL_AMFLAGS like
   this:
    AC_SUBST([ACLOCAL_AMFLAGS], ["-I $ac_macro_dir \${ACLOCAL_FLAGS}"])
   (this should come after AC_CONFIG_MACRO_DIR()).

Now when you run autogen.sh, intltoolize will copy the intltool.m4 macro to the
m4/ subdirectory, and aclocal will reference that version in aclocal.m4 (and
since the same program is copying intltool.m4 and
intltool-{update,merge,extract}.in, those files should be in sync).

Automake >= 1.8 will automatically distribute such referenced macros, so you
shouldn't need to make any makefile changes.

I'm not an autofoo expert so please be gentle with me :-)
This isn't specific to gnome-panel, is it? Every module should be changed like
that...

I'm ok with 1), but 2) won't work since the m4 directory will be empty and won't
be checked out using cvs if people use -p...

The problem with "cvs update -p" can be fixed by putting a .cvsignore file in
the m4/ subdirectory.  This will cause the directory to stick around, and you
probably want the file in order to prevent "intltool.m4" from getting checked
into CVS.

And yes, this is probably something that most packages will want to do in the
future.  Of course, at the moment it only really helps packages that are using a
build tool that can copy m4 files into the macros dir (which will be a lot more
once Libtool 2.0 is out).

Fixed in HEAD. Thanks