Mail Archives: djgpp/2014/04/19/22:01:06
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 existence of
the name clash between the GNU gettext function name with the old BORLAND-
compatibility gettext function in declared in conio.h.
This is NOT optional.
The DJGPP 2.04 version of this port provides the libraries as static
libraries and as DXE3 modules too. To be able to produce working DXE3
modules it is necessary to use a freshly compiled libc.a from the CVS
repository. This 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
occurence 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.
- The following applies to DJGPP 2.04 users _ONLY_:
You can build and use the gettext library either as static library or as a
DXE3 loadble module. To build a static library, stock DJGPP 2.04 is enough.
But if you prefer a module loaded at run-time, you will need to compile and
use a freshly compiled libc.a from the CVS repository source code. 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 2.04 port of gettext has been
configured and compiled as DXE3 module but it contains both versions of the
libraries. The DXE3 modules and binaries compiled with them are stored in
the gnu/gettext-0.18.3.2/djgpp/dxe3 directory of the binary archive.
The static version of the libraries and binaries compiled with libc.a from
the stock djdev204 archive are stored in their usual place so they will be
used as defaults. If you want to use DXE3 modules replace the static
version copying the contents of the /dxe3 directory to your installation
tree. The DXE3 versions of the libraries are always pairs of files. One
is the import library used during the linking of the application, the other
one is the DXE3 module loaded at run time. 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 chosen
intentionally so that linking rules in existing Makefiles do not need to be
adjusted. The sources have been configured for the CVS repository version
of libc.a. 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 test suite
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.
Again, all this concerns the DJGPP 2.04 users only.
- 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/licv114br2.zip
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/luns093br2.zip
and these ones are for the DJGPP 2.03 users:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv114br2.zip
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/luns093br2.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/beta/v2gnu/bnu224br2.zip
and later port versions provides this 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 file names 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/beta/v2gnu/bnu224br2.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 gtx1832br2.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 gtx1832ar2.zip. Most of the users will only need gtx1832br2.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 run time to the dos codepage stipulated by the value of
LANG. This run time 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 matter 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.
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-04-16):
GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832ar2.zip
GNU gettext 0.18.3.2 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832br2.zip
GNU gettext 0.18.3.2 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832dr2.zip
GNU gettext 0.18.3.2 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832sr2.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 (times tamp 2014-04-16):
GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832ar2.zip
GNU gettext 0.18.3.2 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832br2.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>
P.S.: I have removed the previous port gtx1832[b|d|s].zip.
- Raw text -