This is a port of GNU gettext 0.19.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 existance 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 libc.a version compiled from the CVS
  respository.  This is NOT optional.



1.:     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.  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 adjustmens 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.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 loadable module.  Building with stock djdev204 is no longer
        supported due to bugs in different LFN functions that makes the port
        useless on plain DOS together with LFN drivers that do not implement
        the full set of 0x71NN functions.  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 static
        version of the library and the binaries are stored in the
        /gnu/gettext-0.19.2/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.  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
        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.
        Again, all this concerns the DJGPP 2.04 users only.

        To be able to compile AND to use this port, the iconv library must be
        installed.  This is the one for the DJGPP 2.04 users:
          ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/licv114br2.zip
        and this is the one for the DJGPP 2.03 users:
          ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv114br2.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.

        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/beta/v2gnu/bnu224br2.zip
        and later versions of this port provides a lib name mapping feature
        that will allow to use the long fibrary 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 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 the /dir/env/DJDIR/djgpp.env.  

        The LANG entry is obligatory, the LANGUAGE entry may be omited.
        xx, yy and zz stand for some language code while CC stands for some
        country related to that language.  The LANGUAGE variable allows 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 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 noticed 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.


        As usual, all djgpp specific files (config.bat, diffs, README files,
        etc.) are located in the djgpp directory.

        For further information about GNU gettext please read the info docs and NEWS file.


2.:     Installing the binary package.
        ==============================

2.1.:   Copy the binary distribution into the top DJGPP installation directory,
        just unzip it preserving the directory structure running *ONE* of the
        following commands:
          unzip32 gtxt192b.zip      or
          djtarx gtxt192b.zip       or
          pkunzip -d gtxt192b.zip


3.:     Building the binaries from sources.
        ===================================

3.1.:   Create a temporary directory and copy the source package into the
        directory.  If you download the source distribution from one of the
        DJGPP sites, just unzip it preserving the directory structure
        running *ONE* of the following commands:
          unzip32 gtxt192s.zip      or
          djtarx gtxt192s.zip       or
          pkunzip -d gtxt192s.zip

3.2.:   To build the binaries you will need the following binary packages:
          djdev203.zip (or a later but NOT a prior version)
          bsh205bbr3.zip (or a later but NOT a prior version)
          gccNNNb.zip, gppNNN.zip, bnuNNNb.zip, makNNNb.zip, filNNNb.zip,
          shlNNNb.zip, txtNNNb.zip, txiNNNb.zip, grepNNNb.zip, sedNNNb.zip,
          pcreNNNb.zip, mktmpNNb.zip, gwkNNNb.zip, licvNNNb.zip and lunsNNNb.zip

        If you want to run the check you will need also:
          difNNNb.zip and mktmpNNNb.zip

        NNN represents the latest version number of the binary packages.  All
        this packages can be found in the /v2gnu directory of any
        ftp.delorie.com mirror.
        You will need bsh205bbr3.zip or later and *NOT* a prior version or
        the build will fail.  The same applies to djdev203.zip.

3.3.:   The package has been configured for both DJGPP 2.03 and DJGPP 2.04.
        There is a separate build directory for DJGPP 2.03 and for DJGPP 2.04
        under the top srcdir (aka gettext-0.19.2).  To build the binaries
        using the 2.03 version of DJGPP cd into _build.203; if you prefer to
        build the binaries using DJGPP 2.04 cd into _build.204.  If for some
        reason you want to reconfigure the package cd into the corresponding
        build directory and run the following commands:
          del config.cache
          make clean
          ..\djgpp\config ./..

        Please note that you *MUST* delete the config.cache file in the build
        directory or you will not really reconfigure the sources because the
        configuration informations will be read from the cache file instead
        of being newly computed.

        config.bat, among other things, will start the configure script passing
        to it a couple of arguments.  You can control these argument passing the
        following command line arguments to config.bat:
          nls or no-nls, default nls.  NLS support enabled.
          cache or no-cache, default cache.
          dep or no-dep, default no-dep.  No dependency tracking.
          acl or no-acl, default no-acl.
          curses or no-curses, default no-curses.
          threads or no-threads, default no-threads.
          c++ or no-c++, default c++.  C++ support enabled.
          libasprintf or no-libasprintf, default libasprintf.  Create libasprintf.
          emacs or no-emacs, default emacs.  Emacs support enabled.
        All other configure specific options are not set by config.bat so their
        values are left as they are.  If no arguments are passed to config.bat
        then the default values are used.


        To build the programs in a directory other than where the sources are,
        you must add the parameter that specifies the source directory,
        e.g:
          x:\src\gnu\gettext-0.19.2\djgpp\config x:/src/gnu/gettext-0.19.2

        Lets assume you want to build the binaries in a directory placed on a
        different drive (z:\build in this case) from where the sources are,
        then you will run the following commands:
          z:
          md \build
          cd \build
          x:\src\gnu\gettext-0.19.2\djgpp\config x:/src/gnu/gettext-0.19.2

        The order of the options and the srcdir option does not matter.  You
        *MUST* use forward slashes to specify the source directory.

        The batch file will set same environment variables, make MSDOS specific
        modifications to the Makefile.in's and supply all other needed options
        to the configure script.

3.4.:   To compile the package run from the directory where you have configured
        the sources the command:
          make
        This will produce static libraries for DJGPP 2.04.  For DJGPP 2.03, the
        produced libraries are always static.  If you use DJGPP 2.04 and you
        prefer DXE3 modules use the command:
          make MAKE_DXE3

3.5.:   Now you can run the tests if you like.  Start the command:
          make check
        Due to bash issues the scripts used by the test suite do not work.

        If the package has been compiled to produce DXE3 modules, the test suite
        must be started using the command
          make check MAKE_DXE3

        If MAKE_DXE3 is omitted, the makefile will not set the LD_LIBRARY_PATH
        environment variable and the compiled test programs will not be able to
        find and load the DXE3 modules.

3.6.:   To install the binaries and info docs run the following command from
        the directory where you have configured the sources:
          make install

        This will install the products into your DJGPP installation tree given
        by the default prefix "/dev/env/DJDIR".  If you prefer to install them
        into some other directory you will have to set prefix to the appropriate
        value:
          make install prefix=z:/some/other/place




        Send gettext specific bug reports to <bug-gettext@gnu.org>.
        Send suggestions and bug reports concerning the DJGPP port
        to comp.os.msdos.djgpp or <djgpp@delorie.com>.



Enjoy.

      Guerrero, Juan Manuel <juan.guerrero@gmx.de>
