X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-Id: <201403042204.s24M4A47017087@delorie.com> Date: Tue, 04 Mar 2014 23:02:43 +0100 From: Juan Manuel Guerrero To: djgpp-announce AT delorie DOT com Subject: ANNOUNCE: DJGPP port of GNU gettext 0.18.3.2 uploaded. Content-Type: text/plain; charset=ISO-8859-15; format=flowed Reply-To: djgpp AT delorie DOT com 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 . Send suggestions and bug reports concerning the DJGPP port to comp.os.msdos.djgpp or . If you are not sure if the failure is really a gettext failure or a djgpp specific failure, report it here and NOT to . Enjoy. Guerrero, Juan Manuel