Mail Archives: djgpp/2001/09/24/08:57:15
This is a port of GNU Gettext 0.10.40 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. Starting with GNU Gettext 0.10.36, the official GNU gettext
distribution has build-in DJGPP support, so you should be able to build future
official GNU distributions out-of-the-box, as soon as djdev204.zip has been
released. As long as you use djdev203.zip, you should always download the
DJGPP port of GNU gettext. The reason for this is the well known name clash
existing between the BORLAND-compatibility gettext() function declared in
conio.h provided by libc.a and the GNU gettext() function declared in libintl.h
and provided by libintl.a. Only the binary package of the DJGPP ports of
GNU gettext will provide the required files to patch your C library.
The binaries, docs and source packages can be downloaded from Simtel.NET
and mirrors as (timestamp: 2001-09-22):
Gettext 0.10.40 binary, info and man format documentation:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt040b.zip&name=gtxt040b.zip
Gettext 0.10.40 dvi, html and ps format documentation:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt040d.zip&name=gtxt040d.zip
Gettext 0.10.40 source:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt040s.zip&name=gtxt040s.zip
It should be noticed that GNU gettext **DEPENDS** on the GNU libiconv
distribution. This implies that the DJGPP port of libiconv (licv17b.zip or
later) must be downloaded and installed too. The GNU libiconv port provides
the required functionality to the DJGPP port of GNU gettext for on-the-fly
recoding from UNIX charsets to the appropiate MSDOS codepages . This port is
available from Simtel.NET and mirrors as:
Libiconv 1.7 binary and man format documentation:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/licv17b.zip&name=licv17b.zip
Libiconv 1.7 source:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/licv17s.zip&name=licv17s.zip
The installation of GNU libiconv is **NOT** optional, neither for rebuilding
this package from sources nor for using this package in your own aplications.
All future DJGPP ports of GNU distributions that want to provide NLS support
will depend on both ports, GNU gettext and GNU libiconv. For using GNU gettext
in your own projects, you must always link with a command like this:
gcc your_program.c -lintl -liconv
If you link your projects with libintl.a but without libiconv.a you will get
linker errors about unresolved external references in libintl.a.
Users not interested in the on-the-fly recoding capability will have to
reconfigure and recompile the DJGPP port of GNU gettext from scratch. In this
case follow the following steps:
1) Deinstall any existing DJGPP port of libiconv.
This can be done either by really deinstalling the port if it is installed
on your system, or by renaming the %DJDIR%/include/iconv.h file temporarily.
This is needed because the gettext configure script offers no option to
disable the use of libiconv. After the configuration of gettext has been
finish, you can rename iconv.h back to his original name.
2) Install the source package of the DJGPP port of GNU gettext in an appropiate
directory.
3) From the gnu/gtxt-010.40 directory run the following commands:
make distclean
djgpp\config
make
make check
4) To install the products run the command:
make install prefix=x:/some/appropiate/directory
Replace prefix with an apropiate installation path. If no prefix is given at
all the default prefix, this is /dev/env/DJDIR, will be used.
Now, you will have a full functional libintl.a but without any runtime recoding
capabilities.
Although, gettext has build-in DJGPP support, it can not be used with
the stock djdev203.zip distribution. This is because a name conflict
between a libc function and a libintl function existes. 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. If you install the binary package
you will find both files in the %DJDIR%/gnu/gtxt-010.40/djgpp/djdev-2.03
subdirectory (%DJDIR% is the path to your DJGPP installation tree). To
update your libc.a proceed as follows:
1) Cd into the %DJDIR%/gnu/gtxt-010.40/djgpp/djdev-2.03 directory.
First, you should backup your old header and library. For this task,
run the following commands:
mv -fv /dev/env/DJDIR/include/conio.h /dev/env/DJDIR/include/conio.bak
mv -fv /dev/env/DJDIR/lib/libc.a /dev/env/DJDIR/lib/libc.bak
2) Now you can copy the new header into your include directory
running the command:
mv -fv conio.h /dev/env/DJDIR/include
3) Now you can substitute the old conio.o file in libc.a with the new one.
For this task you will need the `ar' program from binutils installed.
Run the command:
ar -rv /dev/env/DJDIR/lib/libc.a conio.o
This will replace in your libc.a the existing conio.o by this new one.
You are done.
Now the name conflict between the BORLAND-Compatibility gettext function and
the GNU gettext function has been removed. To remove this conflict, 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 has not been included 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 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 keyword:
_conio_gettext
in the sources.
Please read the readme file in the djgpp directory to become familiar with all
this.
Setting up your AUTOEXEC.BAT file for NLS.
The NLS controling environment variables, LANG and LANGUAGE, must been set.
The exact way how these variables should be set depends on your operating system:
* For Windows 98 systems:
- Click START;
- Choose Programs->Accessories->System Tools->System Information;
- Click Tools in the menu-bar, then choose "System Configuration";
- Use the tab provided there for editing your AUTOEXEC.BAT as explained below.
* For Windows NT systems:
- Right-click "My Computer", then select "Properties";
- Click the "Environment" tab;
- Add a new variable LANG and LANGUAGE, if needed, and set their values to
the language codes wanted as explained below.
* For all other systems (DOS, Windows 3.X and Windows 95): use any
text editor, e.g. the standard EDIT, to edit the file AUTOEXEC.BAT
in the root directory of the boot drive (usually, C:).
No matter which method you use, the values of the two environment variables
LANG and LANGUAGE should be set like this:
set LANG=xx
set LANGUAGE=yy:zz
The LANG entry is obligatory, the LANGUAGE entry may be omited. The LANGUAGE
variable allows you to select an alternate catalog than the one stipulated by
LANG. Replace xx, yy and zz by the language code of the catalogs you want to
use. It should be noticed that LANGUAGE has *ALWAYS* higher priority than LANG
when both have been set. It should also be noticed 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/WIN95 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:
set 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:
set LANG=es
set 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:
set LANG=es
set 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 noticed that the
locale charset for Sweden is CP850 and not CP437.
In this case, the lines must look like this:
set LANG=en_US
set 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 %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
noticed that it is also possible to select a codepage directely. E.G.: Instead
of setting:
set LANG=en_US
you may directely set:
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:
set LANG=C
or clear it by setting:
set LANG=
The binary package gtxt040b.zip contains all needed files to get NLS support
for the following DJGPP ports:
bison-1.28 (bsn128s.zip)
bison-1.29 (bsn129s.zip)
enscript-1.5.0 (ens150s.zip)
enscript-1.6.1 (ens161s.zip)
enscript-1.6.2 (ens162s.zip)
fileutils-3.16 (fil316s.zip)
fileutils-4.0 (fil40s.zip)
grep-2.4 (grep24s.zip)
id-utils-3.2 (idu32s.zip)
make-3.79.1 (mak3791s.zip)
recode-3.5 (rcode35s.zip)
sed-3.02.80 (sed3028s.zip)
sharutils-4.2c (shar42cs.zip)
sh-utils-2.0i (shl20is.zip)
sh-utils-2.0j (shl20js.zip)
tar-1.12a (tar112as.zip)
texinfo-4.0 (txi40s.zip)
textutils-2.0 (txt20s.zip)
Send GNU gettext specific bug reports to <bug-gnu-utils AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <djgpp AT delorie DOT com> and cc them to me.
Enjoy.
Guerrero, Juan Manuel <st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de>
- Raw text -