RE: Possible po.m4 bug in gettext-0.16.1.tar.gz po.m4 -- using "--statistics" to check for msgfmt

[Mark Moriarty]

I actually built their extras/contrib.
That process downloads, builds, and installs gettext-0.16.1.tar.gz
Within gettext-0.16.1.tar.gz, there is gettext/gettext-runtime/m4/po.m4
That particular file, the po.m4, is "old"  as can be seen at line 1 of it:
# po.m4 serial 13 (gettext-0.15)

Lines 36 - 39 of the po.m4 file, the one that's provided in the tar.gz,
consist of:
  AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,
    [$ac_dir/$ac_word --statistics /dev/null >&]AS_MESSAGE_LOG_FD[ 2>&1 &&
     (if $ac_dir/$ac_word --statistics /dev/null 2>&1 >/dev/null | grep
usage >/dev/null; then exit 1; else exit 0; fi)],
    :)

The test that is performed there is, in effect:
Msgfmt --statistics /dev/null

The test is not good -- msgfmt.exe, the one that is built when gettext
0.16.1 is built, returns an error on that command -- therefore, when
configuring, msgfmt is not found (since there is no successful test).

If lines 37 and 38 are changed, updated, to:
    [$ac_dir/$ac_word --help /dev/null >&]AS_MESSAGE_LOG_FD[ 2>&1 &&
     (if $ac_dir/$ac_word --help /dev/null 2>&1 >/dev/null | grep usage
>/dev/null; then exit 1; else exit 0; 

Then msgfmt is correctly detected (the "| grep usage >/dev/null" succeeds)

Put simply, msgfmt.exe 0.16.1 does not output the word "usage" if you feed
it --statistics /dev/null  Feeding it 
--help  /dev/null does get the desired match ("usage" is found)

-----Original Message-----
From: Bruno Haible [mailto:address@hidden 
Sent: Saturday, October 06, 2007 1:49 PM
To: address@hidden; address@hidden
Subject: Re: Possible po.m4 bug in gettext-0.16.1.tar.gz po.m4 -- using
"--statistics" to check for msgfmt

Mark Moriarty wrote:
> I'm building VLC (VideoLAN Client).

OK. I see vlc-0.8.6c uses the gettext infrastructure from version 0.11.5;
but maybe you have rebuilt that configure files?

> The problem I'm observing is that when configure is run on VLC it 
> knows that it needs to use libintl, but the po.m4 file that's in the 
> gettext v16.1 runtime is old, has a bad switch.

I'm asking for the problem as a factual statement, not for your conclusion
of the cause of the problem.

> Config.log shows:
> configure:22986: checking whether NLS is requested
> configure:22995: result: yes
> configure:23033: checking for msgfmt
> configure: trying /usr/local/bin/msgfmt...
> C:\cygwin\usr\local\bin\msgfmt.exe: error while opening "/dev/null" 
> for
> reading: No such file or directory

OK, from this we see:

  - The gettext macros in use are from version 0.14.2 or newer.
    (Earlier versions did not show the "trying ..." line.)

  - msgfmt was called with argument "/dev/null", tried to
fopen("/dev/null","r")
    and failed.

  - The pathname of itself that msgfmt shows has backslashes, not slashes
    as usual on Cygwin.

Since /dev/null is built-in into the Cygwin libraries, I think the binaries
you are using are mingw binaries, not Cygwin binaries. Are you sure you did
not specify "-mno-cygwin" when you built your gettext binaries?

> If I physically type msgfmt --version in a bash shell, it reports:
> msgfmt.exe (GNU gettext-tools) 0.16.1

Good. As expected.

> Exactly what it should, what is expected.  If I type the command 
> that's contained in gettext-runtime/m4/po.m4:
> Msgfmt --statistics /dev/null
> 
> $ msgfmt --statistics /dev/null
> C:\cygwin\usr\local\bin\msgfmt.exe: error while opening "/dev/null" 
> for
> reading: No such file o
> r directory

Yup. Same as above.

> It generates exactly the error that's being captured in my config.log 
> -- the "grep usage" part of the test doesn't find "usage".

It didn't even get to the "grep usage" part. The line with "grep usage" is
only invoked if the first invocation of "msgfmt --statistics /dev/null"
succeeded. Which it did not.

> Instead, it should be:
> Msgfmt --help /dev/null

Nope. The comments say that the purpose of this test is to exclude early GNU
msgfmt versions. But all GNU msgfmt support the --help option.

So, my guess is that either your binaries are not Cygwin binaries, or that
some installation problem of Cygwin causes the access to /dev/null to fail.

Bruno