Description of problem:
The Makefile.in.in appears not to match autoconf-generated configure scripts.
Several variables are either not substituted properly (@MSGMERGE@), other are
left undefined ($top_builddir). I can reproduce the problem with balsa CVS build
(which works just fine with 7.1, 7.2, debian, mandrake and Solaris).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. cvs -d :pserver:anonymous@@anoncvs.gnome.org:/cvs/gnome co balsa
2. cd balsa
3. ./autogen.sh && make
Actual Results: [autogen output and few lines of make output]
Making all in po
make: Entering directory `/home/pawsa/balsa-1.x/po'
make: *** No rule to make target `/config.status', needed by `Makefile'. Stop.
Expected Results: The compilation should continue.
The make failed because $top_builddir is not defined. It was defined in
gettext-0.10.38-7's Makefile.in.in to ".."
Closer inspection reveals also that Makefile contains unsubstituted variable
MSGMERGE_UPDATE = @MSGMERGE@ --update
This variable did not exist in older releases of gettext.
I know that that fact that something works even on 5 other platforms is not a
proof of correctness but it definetely indicates something. In my opinion,
version of autoconf is out of sync with gettext version. I am not an autoconf
expert but it looks to me autoconf package in RH7.3 should be upgraded or
gettext downgraded to match each other.
Installing RH7.2 gettext-0.10.38-7 (neglecting conflict with emacs) makes the
I have lots of problems building gnumeric (gnome_1_4 branch) or
galeon-1.2 stable branch from CVS. In both cases the GNOME
macros/autogen.sh script fails (I tried both the default and
the additional versions of autoconf and automake - both fail).
I suspect this has something to do with the above mentioned bug.
**Warning**: I am going to run configure' with no arguments.
If you wish to pass any to it, please specify them on the
./autogen.sh' command line.
deletefiles is macros/gnome-gettext.m4
Creating ./aclocal.m4 ...
Running gettextize... Ignore non-fatal messages.
Copying file ABOUT-NLS
Copying file config.rpath
Not copying intl/ directory.
Copying file po/Makefile.in.in
Copying file m4/progtest.m4
Updating Makefile.am (backup is in Makefile.am~)
Adding an entry to ChangeLog (backup is in ChangeLog~)
Please use AM_GNU_GETTEXT([external]) in order to cause
to look for an external libintl.
Please create po/Makevars from the template in po/Makevars.template.
You can then remove po/Makevars.template.
Please run 'aclocal -I m4' to regenerate the aclocal.m4 file.
You need aclocal from GNU automake 1.5 (or newer) to do this.
Then run 'autoconf' to regenerate the configure file.
You will also need config.guess and config.sub, which you can get from
You might also want to copy the convenience header file gettext.h
from the /usr/share/gettext directory into your package.
It is a wrapper around <libintl.h> that implements the configure
Making ./aclocal.m4 writable ...
patching file po/Makefile.in.in
Hunk #1 FAILED at 34.
Hunk #2 FAILED at 86.
Hunk #3 FAILED at 171.
3 out of 3 hunks FAILED -- saving rejects to file
You should update your aclocal.m4' by running aclocal.
Running aclocal -I macros ...
configure.in:601: warning: Cannot check for file existence when
Running automake --gnu ...
Makefile.am:1: required directory ./intl does not exist
**Error**: automake failed.
Add a "--intl" to the gettextize line
Well, it copies the intl directory now. But then it still fails.
(Tell me if you want the latest log)
Please try it for yourself and tell me if it really works for you.
This problem exists with Glade 0.6.4 as well. Anything produced by Glade, and
run with the RH 7.3 default setup refuses to compile. Solution with Glade was
to go back to gettext 0.10.40, at least for now. See the thread starting with
(glade users mailing list) for more on this.
Balsa, Glade, Gnumeric, that's a lot of important apps to break. Could we get
this fixed so that the users aren't running around having to learn the
intricacies of autoconf/autogen/gettext etc themselves?
You need to add "--intl" to the autogen script you run. There are many broken
auto* out there, that doesn't mean gettext is broken (and 0.11 is different from