Re: [bug-gettext] Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)

[Bruno Haible]

Paul Martin wrote:
> On Thu, May 03, 2012 at 12:18:48AM +0200, Bruno Haible wrote:
> 
> > I don't know where you got this history from. AFAIK, GNU 'msgfmt' always
> > created .mo files in native endianness since the beginning (1995),
> > up until 2005-08-26, when the option --endianness was introduced.
> 
> This option is not documented in:
> 
>  * "msgfmt --help" output
>  * its manpage
>  * its Texinfo format manual
> 
> Please document it.

OK, you have a reasonable use-case, so I'm documenting it. Patch attached.

There was an earlier request to document this option also in 2008:
  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209>
  "All I want is for the manpage of msgfmt to explain that --endianness
   {big|little} *is* supported, *why* it is supported and why it is
   important for certain situations."
but I understood the rationale as being runtime optimization of a few CPU
cycles, and that was IMO not a good enough reason to document this option.

Bruno


--- gettext-tools/doc/ChangeLog.orig    Thu May  3 11:54:10 2012
+++ gettext-tools/doc/ChangeLog Thu May  3 11:53:58 2012
@@ -1,3 +1,10 @@
+2012-05-03  Bruno Haible  <address@hidden>
+
+       Document msgfmt option --endianness.
+       * msgfmt.texi: Document the option --endianness.
+       Reported by Paul Martin <address@hidden> via
+       Santiago Vila <address@hidden>.
+
 2012-01-26  Bruno Haible  <address@hidden>
 
        Modernize quoting.
--- gettext-tools/doc/msgfmt.texi.orig  Thu May  3 11:54:10 2012
+++ gettext-tools/doc/msgfmt.texi       Thu May  3 11:50:22 2012
@@ -265,6 +265,19 @@
 @c Currently the README mentions that this constant could be changed by
 @c the installer by changing the value in config.h.  Should this go away?
 
address@hidden address@hidden
address@hidden address@hidden, @code{msgfmt} option}
+Write out 32-bit numbers in the given byte order.  The possible values are
address@hidden and @code{little}.  The default depends on the platform, namely
+on the endianness of the CPU.
+
+MO files of any endianness can be used on any platform.  When a MO file has
+an endianness other than the platform's one, the 32-bit numbers from the MO
+file are swapped at runtime.  The performance impact is negligible.
+
+This option can be useful to produce MO files that are independent of the
+platform.
+
 @item --no-hash
 @opindex address@hidden, @code{msgfmt} option}
 Don't include a hash table in the binary file.  Lookup will be more expensive
--- gettext-tools/src/ChangeLog.orig    Thu May  3 11:54:10 2012
+++ gettext-tools/src/ChangeLog Thu May  3 11:53:10 2012
@@ -1,3 +1,10 @@
+2012-05-03  Bruno Haible  <address@hidden>
+
+       Document msgfmt option --endianness.
+       * msgfmt.c (usage): Document the option --endianness.
+       Reported by Paul Martin <address@hidden> via
+       Santiago Vila <address@hidden>.
+
 2012-01-26  Bruno Haible  <address@hidden>
 
        Modernize quoting.
--- gettext-tools/src/msgfmt.c.orig     Thu May  3 11:54:10 2012
+++ gettext-tools/src/msgfmt.c  Thu May  3 11:42:41 2012
@@ -767,6 +767,9 @@
       printf (_("\
   -a, --alignment=NUMBER      align strings to NUMBER bytes (default: %d)\n"), 
DEFAULT_OUTPUT_ALIGNMENT);
       printf (_("\
+      --endianness=BYTEORDER  write out 32-bit numbers in the given byte 
order\n\
+                                (big or little, default depends on 
platform)\n"));
+      printf (_("\
       --no-hash               binary file will not include the hash table\n"));
       printf ("\n");
       printf (_("\