Message-Id: <200109241244.IAA07997@delorie.com> From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: djgpp-announce AT delorie DOT com Date: Mon, 24 Sep 2001 10:27:34 +0200 Subject: ANNOUNCE: DJGPP port of GNU gettext 0.10.40 uploaded Reply-To: djgpp AT delorie DOT com 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 . Send suggestions and bug reports concerning the DJGPP port to comp.os.msdos.djgpp or and cc them to me. Enjoy. Guerrero, Juan Manuel