bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] Bug#671257: gettext: msgfmt output format prevents multiar


From: Santiago Vila
Subject: [bug-gettext] Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)
Date: Wed, 2 May 2012 22:55:23 +0200 (CEST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

Hello Bruno et al.

A long time ago, people working on embedded systems in Debian had the
idea that it would be a good thing to have .mo files in the same
endianness as the architecture on which they are used.

However, the saving in cpu time was too small to justify the need to
have native endianness everywhere.

Well, the fact is that this change was made in gettext after all, and
now msgfmt creates .mo files in native endianness, but now we see that
not only there is not any benefit but it is even harmful, as it makes
multiarch a lot more difficult because of msgfmt using native
endianness.

To summarize: We would much prefer this behaviour to be reverted,
i.e. we would like msgfmt to create always little endian .mo files, as
before.

If that's not possible, a ./configure option to achieve that would be
nice.

If that's not possible either, I would appreciate that someone tells
me what would be the minimal change to gettext required for that,
because I would be willing to keep such patch in the Debian gettext
package for an indefinite amount of time.

Thanks.

---------- Forwarded message ----------
From: Paul Martin <address@hidden>
To: Debian Bug Tracking System <address@hidden>
Date: Wed, 02 May 2012 19:56:53 +0100
Subject: Bug#671257: gettext: msgfmt output format prevents multiarch migration

Package: gettext
Version: 0.18.1.1-6
Severity: important
Tags: l10n

msgfmt produces binary files which vary dependent on the endianness of 
the system you build on.

As localization files are supposed to be placed in /usr/share/ this 
means that packages with localized strings fail the requirement of 
multiarch of all shared files being identical across architectures. For 
example, bug #670023.

There is a workaround: split such packages in two, with a binary package 
and a localization package. This, I've been told by the FTP team is not 
a desirable action.

The better way out of this (and the one preferred by the FTP team) is 
for msgfmt always to produce .mo files of the same endianness, 
regardless of the platform it's run on.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]