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.  



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 reasons of completness.  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.

        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.  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.

        To be able to compile AND to use this port, the iconv library must be
        installed.  It is available as:
          ftp://ftp.delorie.com/pub/djgpp/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/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 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 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 stored 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 gtx1981b.zip      or
          djtarx gtx1981b.zip       or
          pkunzip -d gtx1981b.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 gtx1981s.zip      or
          djtarx gtx1981s.zip       or
          pkunzip -d gtx1981s.zip

3.2.:   To build the binaries you will need the following binary packages:
          djdev205.zip (or a later but NOT a prior version)
          bsh205bbr4.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

        All this packages can be found in the /v2gnu directory of any
        ftp.delorie.com mirror.  NNN stands for the newest port versions
        available when this port was build but older may do the work as well
        but I have not tested this.

3.3.:   The package has been configured to be build in a separate build directory
        under the top srcdir (aka gtxt-0.19.8.1).  To build the binaries cd
        into /_build directory.  If for some reason you want to reconfigure the
        package cd into the build directory and run the following commands:
          make distclean
          ..\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.  Cache in build directory.
          dep or no-dep, default no-dep.  No dependency tracking.
          silent or no-silent, default silent.  Controls the verbosity of the
                                                build process.
          acl or no-acl, default no-acl.
          curses or no-curses, default no-curses. Curses support disabled.
          threads or no-threads, default no-threads. Threads support disabled.
          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.
          java or no-java, default no-java.  Java support disabled.
          openmp or no-openmp, default no-openmp.  OpenMP support disabled.
        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\gtxt-0.19.8.1\djgpp\config x:/src/gnu/gtxt-0.19.8.1

        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\gtxt-0.19.8.1\djgpp\config x:/src/gnu/gtxt-0.19.8.1

        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.  If 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 GNU 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>
