delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2014/04/19/22:01:06

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-Id: <201404200200.s3K20riv000601@delorie.com>
Date: Sun, 20 Apr 2014 03:53:16 +0200
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: Release 2 of the DJGPP port of GNU gettext 0.18.3.2 uploaded.
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 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 it is necessary to use a freshly compiled libc.a from the CVS
   repository.  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.  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
        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 loadble 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.18.3.2/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 chosen
     intentionally so that linking rules in existing Makefiles do not need to be
     adjusted.  The sources have been configured for the 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 provides this 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 gtx1832br2.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 gtx1832ar2.zip.  Most of the users will only need gtx1832br2.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 run time to the dos codepage stipulated by the value of
     LANG.  This run time 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 matter 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 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-04-16):

     GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832ar2.zip

     GNU gettext 0.18.3.2 binaries, info and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832br2.zip

     GNU gettext 0.18.3.2 dvi, html, pdf and ps format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832dr2.zip

     GNU gettext 0.18.3.2 source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtx1832sr2.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 (times tamp 2014-04-16):

     GNU gettext 0.18.3.2 additional libraries and tools to create catalogs:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832ar2.zip

     GNU gettext 0.18.3.2 binaries, info and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/gtx1832br2.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>


P.S.:  I have removed the previous port gtx1832[b|d|s].zip.

- Raw text -


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