Message-Id: <201406202147.s5KLlJs2004861@delorie.com> Date: Sat, 21 Jun 2014 00:49:47 +0200 From: Juan Manuel Guerrero To: djgpp-announce AT delorie DOT com Subject: ANNOUNCE: DJGPP port of GNU gettext 0.19.1 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.19.1 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 and to use them with other applications it is necessary to use a libc.a version compiled from the current repository source code. This is NOT optional. For all port versions you must install licv114br2.zip and luns093br2.zip before you can use them. For the DJGPP 2.03 version you must also update you libc.a and /include directory with the fixed files stored in the /gnu/libiconv-1.14/djgpp/djgpp-2.03 directory. If you decide to use the DXE3 module version you will have to compile your own libc.a from repository code AND you must use bnu224br2.zip. No previous linker version is capable to resolve multiple symbol definitions that will occur when DXE3 modules of libintl.a and libicnv.a are used. 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. Its 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 included 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.19.1/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 loadable 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.19.1/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 choosen intentionaly so that linking rules in existing Makefiles do not need to be adjusted. The sources have been configured for the use with 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 will provide these 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 gtxt191b.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 gtxt191a.zip. Most of the users will only need gtxt191b.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 controling 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 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 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. This is an verbatim extract of the NEWS file (again, please not that the DJGPP port does not support anything else than C): ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- 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-06-15): GNU gettext 0.19.1 additional libraries and tools to create catalogs: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt191a.zip GNU gettext 0.19.1 binaries, info and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt191b.zip GNU gettext 0.19.1 dvi, html, pdf and ps format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt191d.zip GNU gettext 0.19.1 source: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt191s.zip The binaries have been produced a second time using the stock version of djdev204 beta library and a libc.a version compiled from current repository code. This package is available at ftp.delorie.com and mirrors as (times tamp 2014-06-15): GNU gettext 0.19.1 additional libraries and tools to create catalogs: ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtxt191a.zip GNU gettext 0.19.1 binaries, info and man format documentation: ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtxt191b.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