Bug 65008

Summary:	gettext's Makefile.in.in does not match autoconf-generated configure
Product:	[Retired] Red Hat Linux	Reporter:	Pawel Salek <pawsa>
Component:	gettext	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED NOTABUG	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	chbm, knweiss, michael, rgiles
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-06-10 22:38:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pawel Salek 2002-05-15 21:39:45 UTC

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):
gettext-0.11.1-2

How reproducible:
Always

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[2]: Entering directory `/home/pawsa/balsa-1.x/po'
make[2]: *** No rule to make target `/config.status', needed by `Makefile'.  Stop.


Expected Results:  The compilation should continue.

Additional info:

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
problem disappear.

Comment 1 Karsten Weiss 2002-05-22 17:26:57 UTC

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. 
 
gnumeric> ./autogen.sh 
**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. 
 
processing . 
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 
autoconfiguration 
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 
ftp://ftp.gnu.org/pub/gnu/config/. 
 
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 
--disable-nls 
option. 
 
Making ./aclocal.m4 writable ... 
Running xml-i18n-toolize... 
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 
po/Makefile.in.in.rej 
Running libtoolize... 
You should update your aclocal.m4' by running aclocal. 
Running aclocal  -I macros ... 
Running autoheader... 
configure.in:601: warning: Cannot check for file existence when 
cross compiling 
Running automake --gnu  ... 
Makefile.am:1: required directory ./intl does not exist 
**Error**: automake failed.

Comment 2 Trond Eivind Glomsrxd 2002-05-22 18:38:22 UTC

Add a "--intl" to the gettextize line

Comment 3 Karsten Weiss 2002-05-22 19:24:31 UTC

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.

Comment 4 Need Real Name 2002-06-10 22:38:54 UTC

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
http://lists.ximian.com/archives/public/glade-users/2002-May/001576.html
(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?

Comment 5 Trond Eivind Glomsrxd 2002-07-17 20:09:45 UTC

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
0.10.x )