www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-announce/2014/04/19/22:33:09

Message-Id: <201404200233.s3K2X1Wl003409@delorie.com>
Date: Sun, 20 Apr 2014 04:13:08 +0200
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: Release 2 of DJGPP port of GNU libiconv 1.14 uploaded.
Reply-To: djgpp AT delorie DOT com

This is a port of GNU libiconv 1.14 to MSDOS/DJGPP.


   LIBICONV is a character set conversion library and provides
   an iconv() implementation, for use on systems which don't
   have one, or whose implementation cannot convert from/to Unicode.
   This library provides the required functionality to recode on-the-fly
   from UNIX charsets to MSDOS codepages. The mapping from language codes
   to DOS codepages is contained in the charset.alias file located in the
   /dev/env/DJDIR/lib subdir. Please inspect this file carefully and tell
   me if the selected DOS codepage is correct for your language.

   This update provides DXE3 modules together with their import libraries
   of the static libraries that can replaced them.


   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 unsetenv and locale support to the
   DJGPP 2.04 level.  This concerns DJGPP 2.03 users only and 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.
   =======================

   -  There are no DJGPP specific changes to the sources at all. Starting with
      version 1.6, the official GNU distribution has build-in DJGPP support so
      this package should compile out-of-the-box.  Unfortunately this is no
      longer true for the configuration step.  This package can no longer be
      configured 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
      directories 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.

   -  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 responsibility 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 creates 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).

   -  The port has been configured to be build using DJGPP 2.03 or DJGPP 2.04.
      The port using DJGPP 2.03 provides static libraries only.  But the port
      compiled using DJGPP 2.04 may provide either static libraries or dynamic
      libraries using DJGPP's DXE3 feature.  To build static libraries, libc.a
      from the stock djdev204.zip will be enough.  But to be able to build the
      dynamic libraries using the DXE3 module features you will have to use a
      freshly build libc.a from the CVS repository.  To this purpose you can
      either check out the code from the CVS repository or use the daily updated
      checkout archive provided by Martin Stromberg:
<http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp.cvs.tar.gz>

   -  The following applies to DJGPP 2.03 users _ONLY_:
      To be able to compile AND use libiconv (and GNU gettext) with your
      applications that shall be compiled using djdev203, you will need to
      update the locale and unsetenv support of libc.a to the level provided by
      DJGPP 2.04 and later.  It is also useful to resolve a function name clash
      that exists in libc.a from djdev203.
      The port provides all required locale and unsetenv specific files in the
      djgpp/djgpp-2.03 directory of the binary archive.  These are the header
      files:
        locale.h and stdlib.h
      and the object files:
        lconv.o, setlocal.o, strcoll.o, strftime.o and unsetenv.o
      All source files used are from the CVS repository and are the same object
      files that have been created when I compiled libc.a from the CVS repository
      to create the DJGPP 2.04 port of libiconv.
      To update your DJGPP 2.03 C library and headers proceed as follow:
      1: change into the gnu/libiconv-1.14/djgpp/djgpp-2.03 directory.
      2: replace the locale and stdlib header with the new one like this:
           cp -vf locale.h /dev/env/DJDIR/include/locale.h
           cp -vf stdlib.h /dev/env/DJDIR/include/stdlib.h
      3: replace the object files in your libc.a with the new ones like this:
           ar -rv /dev/env/DJDIR/lib/libc.a *.o
      Now you have enough locale and unsetenv support to use libiconv.a,
      libunistring.a and GNU gettext together with DJGPP 2.03.
      Please note that this procedure is __NOT__ optional and must be done
      before you start using the libraries.  If you do not update libc.a as
      described the port will be useless for you.

      It is also useful to fix a function name clash existing in DJGPP 2.03.
      The function name gettext from the GNU gettext library collides with
      BORLAND-compatibility gettext function name declared in conio.h.  To
      resolve this, conio.h and conio.o must be replaced in your DJGPP 2.03
      installation.
      To update your DJGPP 2.03 C library and header proceed as follow:
      1: extract the binary archive of the gettext port into some temporary
         directory and change into the gnu/gettext-0.18.3.2/djgpp/djgpp-2.03
         directory.
      2: replace the conio header with the new one like this:
           cp -vf conio.h /dev/env/DJDIR/include/conio.h
      3: replace the object file in your libc.a with the new one like this:
           ar -rv /dev/env/DJDIR/lib/libc.a *.o

      It is also worth to update the getpwnam function and the passwd structure.
      They are required for gettext anyway.
      To update your DJGPP 2.03 C library and header proceed as follow:
      1: extract the binary archive of the gettext port into some temporary
         directory and change into the gnu/gettext-0.18.3.2/djgpp/djgpp-2.03
         directory.
      2: replace the conio header with the new one like this:
           cp -vf pwd.h /dev/env/DJDIR/include/pwd.h
      3: replace the object file in your libc.a with the new one like this:
           ar -rv /dev/env/DJDIR/lib/libc.a *.o
      You are done.
      Again, all this concerns the DJGPP 2.03 users only.

   -  The following applies to DJGPP 2.04 users _ONLY_:
      You can build and use the iconv 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 libiconv
      will decrease considerably.  Also it guarantees that all programs use the
      same ported code.  Please note that the 2.04 port of iconv has been confi-
      gured 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/libiconv-1.14/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
      ist the DXE3 module loaded at run time.  The names are:
        /lib/libcharset.a
        /lib/libcharset.dxe
        /lib/libiconv.a
        /lib/libiconv.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
      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 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, compile and run the test suite of this package
      you will need LFN support.

   -  As usual, all DJGPP specific stuff is located in /djgpp dir.

   -  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 option to the config.bat file.

   Please read the documentation to become familiar with this product.


   The binary and source packages can be downloaded from ftp.delorie.com and
   mirrors as (time stamp: 2014-04-12):

     Libiconv 1.14 binary and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv114br2.zip

     Libiconv 1.14 source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv114sr2.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 (time stamp 2014-04-12):

     Libiconv 1.14 binary and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/licv114br2.zip



   Send suggestions and bug reports concerning the DJGPP port to
   comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.  Libiconv specific bugs
   must be reported to <bug-gnu-libiconv AT gnu DOT org>.


   Enjoy.

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


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

- Raw text -


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