Mail Archives: djgpp/2018/03/04/12:17:42
This is a port of GNU gettext 0.19.8.1 to MSDOS/DJGPP.
The GNU gettext package provides the needed tools and library functions
for authors or maintainers of other packages or programs which they want
to see internationalized.
ATTENTION: the support for DJGPP 2.03 has been dropped. The DJGPP 2.05
version of this port provides the libraries as DXE3 modules instead of
static libraries.
DJGPP specific changes.
=======================
- GNU gettext used to have build-in support for DJGPP but this is no
longer true, neither for the source code nor for the configuration
scripts stored in the /djgpp directory of the original distribution.
The package can no longer neither be configured nor compiled out-of-
the-box using the djgpp specific files provided by the GNU distribution.
The djgpp specific configuration files are no longer maintained and
thus useless. I have renamed the original /djgpp directory into
/djgpp.old and kept it for completness reasons. Its content is
completely useless nowadays. Do not use them. The new configuration
files are stored now in the new /djgpp directory. As usual, some major
code adjustments were required to get the gnulibs code working with
djgpp. Also the included libxml had needed some adjustmens to work
with djgpp.
- You can build and use the gettext library either as static library or
as a DXE3 loadable module. Using DXE3 modules has the benefit that the
size of the binaries that use libintl will decrease considerably. Also
it guarantees that all programs use the same ported code. Please note
that the port of gettext has been configured and compiled as DXE3 module
but it contains both versions of the libraries. The static version of
the library and the binaries are stored in the /gnu/gettext-0.19.8.1/djgpp/static
directory of the binary archive. The DXE3 module of the library and
binaries compiled with it are stored in their usual place so they will
be used as defaults. If you want to use the static version instead of
the DXE3 module copy the contents of the /static directory to your
installation tree. The DXE3 version of the library is always a pair
of files. One is the import library used during the linking of the
application, the other one is the DXE3 module loaded at runtime. The
names are:
/lib/libintl.a
/lib/libintl.dxe
The files with the ".a" extension are the import libraries created by
the dxe3gen tool. The ".a" extension for the import libraries has been
choosen intentionaly so that linking rules in existing Makefiles do not
need to be adjusted. To compile DXE3 modules you must compile like this:
make MAKE_DXE3=y
If MAKE_DXE3 is omitted then the normal static libraries will be build
no matter which libc.a has been installed. To run the test suite you
must start make like this:
make check MAKE_DXE3=y
If MAKE_DXE3 is omitted then LD_LIBRARY_PATH will not be set to point to
the freshly build but still not installed DXE3 modules and the testsuite
will fail because the test binaries cannot load the modules at run-time.
To install the products start make like this:
make install prefix=/some/dir MAKE_DXE3=y
If MAKE_DXE3 is omitted then every thing will be installed except for
the DXE3 modules.
- To be able to compile AND to use this port, the iconv library must be
installed. The required port is available as:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv115b.zip
Please do not mix libraries. This port has been compiled with the
above libraries and is supposed to be used with them. I have never
tried any of the old ports of libiconv and I have serious doubts that
it will work.
- To be able to compile your applications using the DXE3 version of the
library you will need the a port of binutils that supports resolving
multiple symbol definitions during linking. The linker provided by:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2291b.zip
and later port versions will provide these features.
- To be able to configure and compile the sources LFN support is required.
- The test suite will fail for approximately half of the checks. The
reason is that the used shell scripts do not work with the bash port.
It usually fails trying to duplicate the file descriptor of STDIN and
things like that. I do not have the time to fix all these pending
issues. The port has been tested by using it.
- The port has been compiled with NLS support enabled so you can expect
that the binaries will talk to you in your mother tongue. If you prefer
no NLS, then reconfigure the sources passing the no-nls option to the
config.bat file.
- Please note that the port does not support neither java, python nor C#
nor whatever else languages may exist that have not been ported with
DJGPP.
- Please note that the original library filenames are not SFN clean.
This concerns the following libraries:
libgettextlib.a --> libgtxtlib.a
libgettextpo.a --> libgtxtpo.a
libgettextsrc.a --> libgtxtsrc.a
The libraries have been renamed to become unique when installed on
plain DOS without LFN support or with LFN support enabled but with
numeric tails disabled.
The linker provided by:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2291b.zip
and later versions of this port provides a lib name mapping feature
that will allow to use the long library file name in makefiles but
have the libraries installed with short file names. If the linker
cannot load the library using the long file name it will try to load
a mapping file and search in it for a short file name associated to
the long file name. If the linker can load the library using the
short file it will continue linking without warning or error message.
- The produced binaries and libraries have been splitted into two packages.
The binary archive, called gtxt1981b.zip, contains only those programs
and libraries together with their documentation required to be able to
provide NLS support for GNU programs that already provides their .po
translation files. All the rest of the programs and libraries together
with sources required to implement NLS support in new projects has been
packed into an archive called gtxt1981a.zip. Most of the users
will only need gtxt1981b.zip. Without this splitting the binary
archive would have had a size of around 41MB and the installed products
would require about 94 MB.
- The NLS controling environment variables, LANG and LANGUAGE, must been
set. The values of the two environment variables LANG and LANGUAGE
should be set like this:
LANG=xx_CC
LANGUAGE=yy:zz
in your /dir/env/DJDIR/djgpp.env.
The LANG entry is obligatory, the LANGUAGE entry may be omited.
xx, yy, zz stand for some language code while CC stands for some country
related to that language. The LANGUAGE variable allows you to select an
alternate catalog than the one stipulated by LANG. It should be noted
that LANGUAGE has always higher priority than LANG when both have been
set. It should also be noted that the LANG variable not only selects a
catalog, it also specifies the dos codepage that will be used as locale
charset. All this means that the translation strings contained in the
catalogs (.mo files) will be recoded at runtime to the dos codepage
stipulated by the value of LANG. This runtime recoding is needed because
the .mo files may have been written using a charset that is not compatible
with the charset that will be used on the machine and OS where the .mo
file contents will be displayed. The .po files of the GNU packages,
from which the .mo files are generated, are typical examples of this.
Usualy, they have been written using some ISO-8859-nn charset (an unix
charset) and shall be displayed on a DOS/WIN32 machine that uses some
dos codepage.
Some examples:
If you only want to use the catalog containing the translations for
your mother tongue (in my case the spanish translations) the above
lines will only use the LANG variable and will look like this:
LANG=es
In this case, LANG defines the translation to be used and at the same
time the locale charset (CP850 in this case) to be used for the on-the-
fly recoding of the catalog (.mo file) contents. If you want to use
the spanish (es) and german (de) catalogs the above lines will look
like this:
LANG=es
LANGUAGE=es:de
In this case a DJGPP binary that has been compiled with NLS support
will first search for the spanish translation of a string. If a
translation for that particular string can not be found in the spanish
.mo file then it will search for a german translation of that string
in the german .mo file and if a german translation of that string can
also not been found it will default to display the build-in english
string. No mather if a spanish, a german or an english build-in
string is selected, the string is always recoded to the dos codepage
stipulated by LANG. In this case:
CP850.
If you want to reverse this search order the above lines would look
like this one:
LANG=es
LANGUAGE=de:es
Now let us assume that an user wants to use the swedish catalogs on
a machine that loads codepage CP437 when it is booted. It should be
noted that the locale charset for Sweden is CP850 and not CP437. In
this case, the lines must look like this:
LANG=en_US
LANGUAGE=sv
LANG reflects the available codepage/charset and LANGUAGE selects the
wanted translation catalog. en_US means CP437. Now, the contents of
the catalog are recoded to CP437 instead to CP850 because CP437 is the
codepage used to display messages on screen. Of course, not every
combination of catalogs and locale charset (dos codepages) makes sense.
E.G.: selecting as locale charset chinese (LANG=zh_TW) and the french
translations (LANGUAGE=fr) will certainly not generate an usefull screen
output. The content of LANG is a language code. Examples are fr for
french, en_US for US english, etc. This language code is an alias for
the locale charset (codepage) to be used for runtime recoding. The
complete list of all available aliases can be found in /dev/env/DJDIR/lib/charset.alias.
This file is a table with two entries: left entry is the alias (en_US,
de_AT, etc.), right entry is the corresponding dos codepage that will
be used for that language code (alias). It should be noted that it is
also possible to select a codepage directely. E.G.: Instead of setting:
LANG=en_US
you may directely set:
LANG=CP437
This overwrites any settings in charset.alias. Please note that if
you omit the LANG environment variable, the LANGUAGE variable will
not be honored at all. Because the information about what locale
charset shall be used is needed, if LANG is omitted by the user,
LANGUAGE will be ignored and no translation will be done at all.
If for some reason you want to disable NLS, then you should comment
out the LANG variable, select 'C' as your catalog:
LANG=C
or clear it.
- This port provides NLS support. It has been configured with NLS
support enabled. If you prefer no NLS, then reconfigure the sources
passing the no-nls flag to the config.bat file.
- The port has been configured and compiled on WinXP SP3. There is
no guarantee that this may be possible with any other DOS-like OS.
Due to the massive use of long file names it will not be possible
to configure and compile without LFN support.
All the changes done to the original distribution are documented in the
diffs file and located together with all the files needed to configure
the package (config.bat, config.sed, config.site, etc.) in the /djgpp
directory.
For further information about GNU gettext please read the info docs and NEWS file.
This is a verbatim extract of the NEWS file (again, please not that the
DJGPP port does not support anything else than C):
-------------------------------------------------------------------------------
Version 0.19.8 - June 2016
* Support for reproducible builds:
- msgfmt now produces little-endian .mo files by default.
* Programming languages support:
- XML:
xgettext and msgfmt now look for .its files in directories
supplied through the GETTEXTDATADIRS or XDG_DATA_DIRS environment
variable.
- JavaScript
xgettext and msgfmt now recognize numbered arguments in format
strings.
* Portability:
- Improve OS/2 kLIBC support.
- Fix libintl compilation issue with pre-C99 compilers. It was a
regression since 0.19.5.
- The AM_GNU_GETTEXT Autoconf macro can now detect musl-libc's
gettext as a compatible implementation.
Version 0.19.7 - December 2015
* Programming languages support:
- XML:
xgettext can now load custom string extraction rules supplied by
consumer projects. The rules are written in XML, utilizing the
Internationalization Tag Set (ITS) standard. All the existing
XML-based language scanners (Glade, GSettings, and AppData) are
rewritten using ITS. In addition, msgfmt now has --xml option to
merge translations back to the original XML document.
* Portability:
- Improve OS/2 kLIBC support (still not complete)
- Remove dependency on expat
Version 0.19.6 - September 2015
* Programming languages support:
- AppData:
xgettext now supports AppData file format, used by software center
applications (e.g., GNOME Software) to describe installable
applications.
* A new macro AM_GNU_GETTEXT_REQUIRE_VERSION can be used to indicate
autopoint to pull the latest available infrastructure, instead of
the exact version specified with AM_GNU_GETTEXT_VERSION. When
AM_GNU_GETTEXT_REQUIRE_VERSION is used, AM_GNU_GETTEXT_VERSION is
ignored.
* po/Makefile.in.in can now insert the file $(DOMAIN).pot-header to
$(DOMAIN).pot, instead of the standard header comments.
* Bug fixes:
- Fix mishandling of gettext version numbers for minor releases, in
po-mode.el and gettextize.
- Fix build with --enable-relocatable.
Version 0.19.5 - July 2015
* xgettext now has a feature to perform syntax checks on msgid, which
could enforce common styles of translatable strings, such as to
prefer Unicode characters to the corresponding ASCII characters.
They can be enabled with --check option or special "xgettext: "
comment in the source code. By default, no syntax checks are
enabled.
* msgfilter and msgexec now have an option --newline, which appends a
newline character to filter input and trims it from the filter
output. This would allow filter programs to be more POSIX friendly.
* The base Unicode standard is now updated to 8.0.0. This
particularly improves "\N{...}" notation handling of xgettext for
Perl and Python.
* msginit is now capable of generating "Plural-Forms:" from Unicode
CLDR. This feature is still experimental, but you can try it by
setting the GETTEXTCLDRDIR environment variable pointing to the
directory where the CLDR archive is extracted. The actual
conversion is done by a helper program 'cldr-plural', which can be
used as a generic converter and evaluator of CLDR plural forms.
* Programming languages support:
- C++ with KDE: xgettext and msgfmt can now recognize KUIT (KDE User
Interface Text) markup. See the documentation section "KUIT
Format Strings" for more info.
- C++ with KDE: xgettext now recognizes all default KDE keywords.
This removes the need for a long list of --keyword and --flag
options to perform a reasonable extraction.
* Bug fixes:
- xgettext C++11 raw string recognition is now stricter and don't
accept unbalanced delimiters.
- Suppress baseless warnings which msgfmt emits when processing a
.desktop file.
- xgettext line wrapping behaviour is now consistent between comment
lines and non-comment lines.
- Fix msgfilter-7 test failure on some platforms.
- Fix VPATH build.
Version 0.19.4 - December 2014
* The --keyword option of xgettext now accepts same argument number
for both singular and plural forms.
* Programming languages support:
- C#: xgettext now properly handles Unicode characters encoded with
surrogate pairs.
- C/C++: xgettext now recognizes ISO/IEC 9899:2011 string literals
prefixed by R, u8, u8R, u, uR, U, UR, L, or LR.
- Shell: xgettext now properly recognizes Bash ANSI-C quoting ($'...').
* Bug fixes:
- Fix integer overflow when reading certain MO files with msgunfmt.
- Avoid invalid memory access in various cases. In particular, when
the same argument number is specified for singular/plural
arguments, and when checking Lisp and Scheme format strings.
* Portability:
- Building on Mac OS X 10.10 and AIX 7.1 is now supported.
Version 0.19.3 - October 2014
* Bug fixes:
- Fix xgettext mishandling of octal character escapes in C.
- Fix autopoint infinite recursion with certain configure.ac.
* The po/Makevars file has a new field MSGINIT_OPTIONS, that can be
used to adjust msginit's operation. This is particularly useful for
controlling line wrapping behavior together with MSGMERGE_OPTIONS
and XGETTEXT_OPTIONS.
* Portability:
- Building on Solaris 10 and 11 with Solaris Studio compiler is now
fixed.
-------------------------------------------------------------------------------
The port consists of the usual four packages that have been produced
using djdev205 and can be downloaded from ftp.delorie.com and mirrors
as (time stamp 2018-02-11):
Gettext 0.19.8.1 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981a.zip
Gettext 0.19.8.1 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981b.zip
Gettext 0.19.8.1 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981d.zip
Gettext 0.19.8.1 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981s.zip
Send gettext specific bug reports to <bug-gettext AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port
to comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a gettext
failure or a djgpp specific failure, report it here and
NOT to <bug-gettext AT gnu DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -