reopen 468209 quit On Thu, 28 Feb 2008 12:10:23 +0100 (CET) Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Wed, 27 Feb 2008, Neil Williams wrote:
> > msgfmt does support --endianness {big|little} from the source in
> > gettext-tools/src/msgfmt.c
> >
> > [EMAIL PROTECTED]:po$ file messages.mo
> > messages.mo: GNU message catalog (little endian), revision 0, 14
> > messages
> > [EMAIL PROTECTED]:po$ msgfmt --endianness big cs.po
> > [EMAIL PROTECTED]:po$ file messages.mo
> > messages.mo: GNU message catalog (big endian), revision 0, 14 messages
> > [EMAIL PROTECTED]:po$
> >
> > Please document this in the manpage and ask upstream if it can also be
> > output in the --help output.
> >
> > (endianness is important when crossbuilding packages containing PO
> > files.)
>
> No, it is not. Binary .mo files as used by libc and gettext are always
> little endian, regardless of the machine architecture.
Not necessarily. That is just how gettext currently works but it is not
how gettext *must* work, hence the --endianness option in the source
code.
> Otherwise it
> would be impossible for us to have "Architecture: all" packages
> like util-linux-locales containing just binary .mo files.
>
Actually, endianness *IS* important because we should not be *having*
Architecture:all packages that contian .mo files - that was
demonstrated during my talk on TDebs at Fosdem.
On big endian systems, the CPU wastes time converting the endianness at
loadtime which is important for embedded devices.
All packages containing .mo files should be Arch:any and this is
something I will be fixing during the course of TDeb development in
Debian. All the other questions that arise from this (increased package
numbers, extra builds, repository implications, userspace controls and
cache sizes) have all got solutions that are currently working in
Emdebian and which are due to be applied to Debian (probably after
Lenny).
TDebs might also need to drop the hash table in the .mo, again
discussed at Fosdem, but I'm currently working on whether that is
necessary and whether it has positive or negative consequences on the
use of .mo files on embedded devices.
I started working on TDebs for Emdebian thinking exactly the same way,
that .mo files were immune to other problems of endianness etc. (The
slides at Fosdem claimed that TDeb packages would be Arch:all until
the question and answer section of the talk). They are not Arch:all. It
is just that msgfmt defaults to little unless --endianness is specified,
irrespective of the build machine architecture.
In some ways, this is a bug but documenting the --endianness option
allows others to not make the same mistake again.
.mo files *are* architecture dependent and should be handled as such.
Just because 'it happens to work' right now does not mean it is the
correct way to handle .mo files.
Source packages that put .mo files into an Arch:all binary are buggy -
implementing that fix will involve lots of work in Debian to handle the
increase in package numbers but leave that to me - I'll sort out the
mass bug filing(s) when other TDeb support is implemented elsewhere in
Debian after Lenny. (In fact, these bugs will simply disappear anyway
because the implementation of TDebs means that *no* other package in
Debian would contain any .mo files, all .mo files would only exist in
TDeb packages which will be Architecture:any.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpF9FNYCdpao.pgp
Description: PGP signature
