X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-Id: <201906300304.x5U34Frc003911@delorie.com> Date: Sun, 30 Jun 2019 02:03:43 +0200 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.20.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.20.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. DJGPP specific changes. ======================= - There are no user visible DJGPP specific changes to the sources. The official GNU distribution has build-in DJGPP to some degree but this support has ceased, so that new changes must be ported to DJGPP. Especially for included support libraries like libxml2 and the posix specific library relocation support that has been completely disabled by me because it makes no sense on DOS/DJGPP. - It is important to understand that this port does not have nor will ever provide code to identify SFN aliases that have numeric tails. IOW, it is the user's responsability to disable numeric tail generation on all OS where this is possible before installing packages that have NLS support or the program compiled with this library will fail when LFN support has been disabled. E.g.: the port will be able to find a file like charset.alias if LFN support is enabled and it will be able to find charset.ali if LFN support is disabled but it will never be able to find charset~1.ali. On WIN95/98 systems and plain DOS with DOSLFN, the user _must_ always turn off the generation of numeric tails for 8.3 aliases the OS creats for long file names _before_ package installation or the package will not work in a dual DOS/WIN9X (SFN/LFN) environment (it will work on Win[9X|2K|XP] where the long file name (charset.alias) is available but it will not work on plain DOS where an alias like charset~1.ali will be visible instead of the 8.3 truncated short file name, this is charset.ali). - Due to various new issues DXE3 modules will not be provided. - 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/licv116b.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 gtxt201b.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 gtxt201a.zip. Most of the users will only need gtxt201b.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 and Win98SE. There is no guarantee that this may be possible with any other DOS- like OS. Due to the 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. Here is an extract of the NEWS file showing the user visible changes from the last port (GNU gettext 0.19.8.1) to this one (again, please not that the DJGPP port does not support anything else than C): ------------------------------------------------------------------------------- Version 0.20.1 - May 2019 * Important bug fix: - Fixed a wrong shared library versioning of libintl.so. Version 0.20 - May 2019 * Support for reproducible builds: - msgfmt now eliminates the POT-Creation-Date header field from .mo files. * Improvements for translators: - update-po target in Makefile.in.in now uses msgmerge --previous. * Improvements for maintainers: - msgmerge now has an option --for-msgfmt, that produces a PO file meant for use by msgfmt only. This option saves processing time, in particular by omitting fuzzy matching that is not useful in this situation. - The .pot file in a 'po' directory is now erased by "make maintainer-clean". - It is now possible to override xgettext options from the po/Makefile.in.in through options in XGETTEXT_OPTIONS (declared in po/Makevars). - The --intl option of the gettextize program (deprecated since 2010) is no longer available. Instead of including the intl sources in your package, we suggest making the libintl library an optional prerequisite of your package. This will simplify the build system of your package. - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone as well. * Programming languages support: - C, C++: xgettext now supports strings in u8"..." syntax, as specified in C11 and C++11. - C, C++: xgettext now supports 'p'/'P' exponent markers in number tokens, as specified in C99 and C++17. - C++: xgettext now supports underscores in number tokens. - C++: xgettext now supports single-quotes in number tokens, as specified in C++14. - Shell: o The programs 'gettext', 'ngettext' now support a --context argument. o gettext.sh contains new function eval_pgettext and eval_npgettext for producing translations of messages with context. - Java: o xgettext now supports UTF-8 encoded .properties files (a new feature of Java 9). o The build system and tools now support Java 9, 10, and 11. On the other hand, support for old versions of Java (Java 5 and older, GCJ 4.2.x and older) has been dropped. - Perl: o Native support for context functions (pgettext, dpgettext, dcpgettext, npgettext, dnpgettext, dcnpgettext). o better detection of question mark and slash as operators (as opposed to regular expression delimiters). - Scheme: xgettext now parses the syntax for specialized byte vectors (#u8(...), #vu8(...), etc.) correctly. - Pascal: xgettext can now extract strings from .rsj files, produced by the Free Pascal compiler version 3.0.0 or newer. - Vala: xgettext now parses escape sequences in strings more accurately. - JavaScript xgettext now parses template literals correctly. * Runtime behaviour: - The interpretation of the language preferences on macOS has been fixed. - Per-thread locales are now also supported on Solaris 11.4. - The replacements for the printf()/fprintf()/... functions that are provided through on native Windows and NetBSD are now POSIX compliant. There is no conflict any more between these replacements and other possible replacements provided by gnulib or mingw. * Libtextstyle: - This package installs a new library 'libtextstyle', together with a new header file . It is a library for styling text output sent to a console or terminal emulator. Packagers: please see the suggested packaging hints in the file PACKAGING. ------------------------------------------------------------------------------- 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 2019-06-29): Gettext 0.20.1 additional libraries and tools to create catalogs: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201a.zip Gettext 0.20.1 binaries, info and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201b.zip Gettext 0.20.1 dvi, html, pdf and ps format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201d.zip Gettext 0.20.1 source: ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201s.zip Send GNU 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