delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2018/03/04/12:17:42

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]" <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.
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 <bug-gettext AT gnu DOT org>.
   Send suggestions and bug reports concerning the DJGPP port
   to comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
   If you are not sure if the failure is really a gettext
   failure or a djgpp specific failure, report it here and
   NOT to <bug-gettext AT gnu DOT org>.

Enjoy.

       Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019