Mail Archives: djgpp/2014/03/04/17:04:39
This is a port of GNU gettext 0.18.3.2 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: to compile and use this port with DJGPP 2.03 you will have to
replace some headers in your installation and replace some object files in
your libc.a This is required to update getpwnam and unsetenv support to
the DJGPP 2.04 level. Even more important is to resolve the existance of
the name clash between the GNU gettext function name with the old BORLAND-
compatibility gettext function in declared in conio.h.
This concerns DJGPP 2.03 users only and is NOT optional.
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
completeness reasons. Their 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 include libxml had
needed some adjustments to work with djgpp.
To be able to use this port with DJGPP 2.03, libc.a needs to be adjusted
too.
- The following applies to DJGPP 2.03 users _ONLY_:
There is a name conflict between a libc function of djdev203 and a libintl
function. DJGPP's libc contains a BORLAND-compatibility function called
gettext. This name collides with the gettext function provided by libintl.
This DJGPP port of GNU gettext provides a new conio.h and a recompiled
conio.o file that will remove the existing name clash. It is also required
to update djdev203's getpwnam support to djdev204 level. To update your
library proceed as follows:
1) Change into the gnu/gettext-0.18.3.2/djgpp/djdev-2.03 directory and copy
the new header into your include directory of your djgpp installation tree
running the command:
mv -fv *.h /dev/env/DJDIR/include
This will copy conio.h and pwd.h into your /include directory.
2) Now replace the conio.o and getpwnam.o files in your libc.a with the new
ones provided by this port by running the command:
ar -rv /dev/env/DJDIR/lib/libc.a *.o
You are done.
Please note that these changes are NOT optional and need to be done so that
this port and the ports of libunisting 0.9.3 and libiconv 1.14 will work
with djdev203.
To remove the name conflict of gettext, the BORLAND compatibility function
has been renamed into _conio_gettext. At the same time a code snippet has
been added to conio.h. This code will check if libintl.h has been included
or not by the source file. If libintl.h has been include, the keyword
gettext will be assigned to the GNU gettext function and the BORLAND-
compatibility function gettext will no longer be available as gettext.
In this case the BORLAND-compatibility function will only be available as
_conio_gettext. This implies that the keyword gettext is always assigned
to the GNU gettext function and never to the BORLAND_compatibility function
from libc.a if both headers, libintl.h and conio.h, are included by the same
source file. Of course, the goal of all this is not only to remove the name
clash between both functions, but also to keep the user visible changes as
small as possible. All this has the following implications:
1) Sources that use BORLAND-compatibility gettext and do NOT use GNU gettext
can still be compiled without any change and/or difficulty with the new
C library and header. This is because this sources will include only
conio.h and not libintl.h. In this case the gettext keyword will
continue making reference to the BORLAND-compatibility function defined
in conio.c. In this case the updated DJGPP libc.a will not exhibit any
user visible change.
2) Sources that use GNU gettext and do NOT use BORLAND-compatibility
gettext can also still be compiled without any change and/or difficulty.
This sources will include only libintl.h and will not include conio.h
so the sources will never see the BORLAND-compatibility gettext
declaration in conio.h. Also in this case the updated DJGPP libc.a
will not exhibit any user visible change.
3) Sources that use GNU gettext AND BORLAND-compatibility gettext can NOT
be compiled without some changes. This sources will include both headers,
libintl.h and conio.h. In this case the keyword gettext will ALWAYS be
reserved for the GNU gettext function and will NEVER make reference to
the BORLAND-compatibility gettext function. This function will now only
be available as _conio_gettext. The user will have to replace EVERY
occurrence of the BORLAND-compatibility gettext function by the new
function name _conio_gettext in the sources.
Again, all this only concerns the DJGPP 2.03 users; neither the DJGPP 2.04
users nor the users that use a libc.a compiled from the sources of the CVS
repository.
- To be able to compile AND to use this port, the iconv library and the Unicode
string library must be installed. These are the ones for the DJGPP 2.04
users:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/licv114b.zip
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/luns093b.zip
and these ones are for the DJGPP 2.03 users:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv114b.zip
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/luns093b.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 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 produced binaries and libraries have been divided into two packages.
The binary archive, called gtx1832b.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 gtx1832a.zip. Most of the users will only need gtx1832b.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 controlling 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 directly 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.
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.
The source package is now distributed configured for both DJGPP 2.03 and
DJGPP 2.04. In the top srcdir there is be a "_build.203" directory and a
"_build.204" directory.
For further information about GNU gettext please read the info docs and NEWS file.
The port has been compiled using stock djdev203 (patchlevel 2) and consists
of the usual three packages that can be downloaded from ftp.delorie.com and
mirrors as (time stamp 2014-03-01):
GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832a.zip
GNU gettext 0.18.3.2 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832b.zip
GNU gettext 0.18.3.2 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832d.zip
GNU gettext 0.18.3.2 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832s.zip
The binaries have been produced a second time using the stock version of
djdev204 beta library. This package is available at ftp.delorie.com and
mirrors as (time stamp 2014-03-01):
GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832a.zip
GNU gettext 0.18.3.2 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832b.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 -