X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-Id: <201803041717.w24HHe8f032450@delorie.com> Date: Sun, 04 Mar 2018 14:34:38 +0100 From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-announce AT delorie DOT com]" To: djgpp-announce AT delorie DOT com Subject: ANNOUNCE: DJGPP port of GNU gettext 0.19.8.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.8.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: the support for DJGPP 2.03 has been dropped. The DJGPP 2.05 version of this port provides the libraries as DXE3 modules instead of static libraries. 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 completness 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 adjustmens to work with djgpp. - You can build and use the gettext library either as static library or as a DXE3 loadable module. 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 port of gettext has been configured and compiled as DXE3 module but it contains both versions of the libraries. The static version of the library and the binaries are stored in the /gnu/gettext-0.19.8.1/djgpp/static directory of the binary archive. The DXE3 module of the library and binaries compiled with it are stored in their usual place so they will be used as defaults. If you want to use the static version instead of the DXE3 module copy the contents of the /static directory to your installation tree. The DXE3 version of the library is always a pair of files. One is the import library used during the linking of the application, the other one is the DXE3 module loaded at runtime. 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. 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 testsuite 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. - To be able to compile AND to use this port, the iconv library must be installed. The required port is available as: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv115b.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/current/v2gnu/bnu2291b.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 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 linker provided by: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2291b.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 gtxt1981b.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 gtxt1981a.zip. Most of the users will only need gtxt1981b.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. - This port provides NLS support. It has been configured with NLS support enabled. If you prefer no NLS, then reconfigure the sources passing the no-nls flag to the config.bat file. - The port has been configured and compiled on WinXP SP3. There is no guarantee that this may be possible with any other DOS-like OS. Due to the massive use of long file names it will not be possible to configure and compile without LFN support. 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. For further information about GNU gettext please read the info docs and NEWS file. This is a verbatim extract of the NEWS file (again, please not that the DJGPP port does not support anything else than C): ------------------------------------------------------------------------------- Version 0.19.8 - June 2016 * Support for reproducible builds: - msgfmt now produces little-endian .mo files by default. * Programming languages support: - XML: xgettext and msgfmt now look for .its files in directories supplied through the GETTEXTDATADIRS or XDG_DATA_DIRS environment variable. - JavaScript xgettext and msgfmt now recognize numbered arguments in format strings. * Portability: - Improve OS/2 kLIBC support. - Fix libintl compilation issue with pre-C99 compilers. It was a regression since 0.19.5. - The AM_GNU_GETTEXT Autoconf macro can now detect musl-libc's gettext as a compatible implementation. Version 0.19.7 - December 2015 * Programming languages support: - XML: xgettext can now load custom string extraction rules supplied by consumer projects. The rules are written in XML, utilizing the Internationalization Tag Set (ITS) standard. All the existing XML-based language scanners (Glade, GSettings, and AppData) are rewritten using ITS. In addition, msgfmt now has --xml option to merge translations back to the original XML document. * Portability: - Improve OS/2 kLIBC support (still not complete) - Remove dependency on expat Version 0.19.6 - September 2015 * Programming languages support: - AppData: xgettext now supports AppData file format, used by software center applications (e.g., GNOME Software) to describe installable applications. * A new macro AM_GNU_GETTEXT_REQUIRE_VERSION can be used to indicate autopoint to pull the latest available infrastructure, instead of the exact version specified with AM_GNU_GETTEXT_VERSION. When AM_GNU_GETTEXT_REQUIRE_VERSION is used, AM_GNU_GETTEXT_VERSION is ignored. * po/Makefile.in.in can now insert the file $(DOMAIN).pot-header to $(DOMAIN).pot, instead of the standard header comments. * Bug fixes: - Fix mishandling of gettext version numbers for minor releases, in po-mode.el and gettextize. - Fix build with --enable-relocatable. Version 0.19.5 - July 2015 * xgettext now has a feature to perform syntax checks on msgid, which could enforce common styles of translatable strings, such as to prefer Unicode characters to the corresponding ASCII characters. They can be enabled with --check option or special "xgettext: " comment in the source code. By default, no syntax checks are enabled. * msgfilter and msgexec now have an option --newline, which appends a newline character to filter input and trims it from the filter output. This would allow filter programs to be more POSIX friendly. * The base Unicode standard is now updated to 8.0.0. This particularly improves "\N{...}" notation handling of xgettext for Perl and Python. * msginit is now capable of generating "Plural-Forms:" from Unicode CLDR. This feature is still experimental, but you can try it by setting the GETTEXTCLDRDIR environment variable pointing to the directory where the CLDR archive is extracted. The actual conversion is done by a helper program 'cldr-plural', which can be used as a generic converter and evaluator of CLDR plural forms. * Programming languages support: - C++ with KDE: xgettext and msgfmt can now recognize KUIT (KDE User Interface Text) markup. See the documentation section "KUIT Format Strings" for more info. - C++ with KDE: xgettext now recognizes all default KDE keywords. This removes the need for a long list of --keyword and --flag options to perform a reasonable extraction. * Bug fixes: - xgettext C++11 raw string recognition is now stricter and don't accept unbalanced delimiters. - Suppress baseless warnings which msgfmt emits when processing a .desktop file. - xgettext line wrapping behaviour is now consistent between comment lines and non-comment lines. - Fix msgfilter-7 test failure on some platforms. - Fix VPATH build. Version 0.19.4 - December 2014 * The --keyword option of xgettext now accepts same argument number for both singular and plural forms. * Programming languages support: - C#: xgettext now properly handles Unicode characters encoded with surrogate pairs. - C/C++: xgettext now recognizes ISO/IEC 9899:2011 string literals prefixed by R, u8, u8R, u, uR, U, UR, L, or LR. - Shell: xgettext now properly recognizes Bash ANSI-C quoting ($'...'). * Bug fixes: - Fix integer overflow when reading certain MO files with msgunfmt. - Avoid invalid memory access in various cases. In particular, when the same argument number is specified for singular/plural arguments, and when checking Lisp and Scheme format strings. * Portability: - Building on Mac OS X 10.10 and AIX 7.1 is now supported. Version 0.19.3 - October 2014 * Bug fixes: - Fix xgettext mishandling of octal character escapes in C. - Fix autopoint infinite recursion with certain configure.ac. * The po/Makevars file has a new field MSGINIT_OPTIONS, that can be used to adjust msginit's operation. This is particularly useful for controlling line wrapping behavior together with MSGMERGE_OPTIONS and XGETTEXT_OPTIONS. * Portability: - Building on Solaris 10 and 11 with Solaris Studio compiler is now fixed. ------------------------------------------------------------------------------- The port consists of the usual four packages that have been produced using djdev205 and can be downloaded from ftp.delorie.com and mirrors as (time stamp 2018-02-11): Gettext 0.19.8.1 additional libraries and tools to create catalogs: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981a.zip Gettext 0.19.8.1 binaries, info and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981b.zip Gettext 0.19.8.1 dvi, html, pdf and ps format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981d.zip Gettext 0.19.8.1 source: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1981s.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