Mail Archives: djgpp/2001/08/08/20:04:45
This is a port of GNU Gettext 0.10.39 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:
Gettext 0.10.39 binary, info and man format documentation:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt039b.zip&name=gtxt039b.zip
Gettext 0.10.39 dvi, html and ps format documentation:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt039d.zip&name=gtxt039d.zip
Gettext 0.10.39 source:
http://www.simtel.net/gnudlpage.php?product=/gnu/djgpp/v2gnu/gtxt039s.zip&name=gtxt039s.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.39 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 appropiate 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 on-the-fly 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.39/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.39/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 same 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 and only 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 and 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 djgpp.env file for NLS.
This port and some other ports offer NLS, this means that you can expect the
programs to talk your mother tongue if supported. To activate this native
language support (NLS) some new entries must be added to the global part of
your djgpp.env.
Add the following lines to the global part of your djgpp.env:
+LANG=xx
+LANGUAGE=yy:zz
The lines must be completely shifted to the left in your djgpp.env file.
Please note the plus sign at the beginning of the line. This plus sign
should **NOT** be omited or a lot of shell scripts, in this and in
other packages, that try to reset this value will stop working. 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. It should also be notice that the
LANG environment 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 files contents will
be displayed. The .po files of the GNU packages, from which the .mo files
are generated, are typical examples of this. 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:
+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 certain 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 the search order defined by LANGUAGE, the above lines
will 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 ( like in the US) when it is booted. This is a case
where the locale charset for the selected language does *NOT* match the used
and selected (by LANG) locale charset. It should be noticed 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
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:
+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 for runtime recoding 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
either comment out the LANG variable or select 'C' as your catalog:
+LANG=C
The binary package gtxt039b.zip contains all needed files to get NLS support
for the following DJGPP ports:
bison-1.28 (bsn128s.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 -