delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/23/17:35:18

From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization: Darmstadt University of Technology
To: Bruno Haible <haible AT ilog DOT fr>
Date: Fri, 23 Feb 2001 23:34:33 +0200
MIME-Version: 1.0
Subject: Re: DJGPP specific patch for libiconv-1.5.1
CC: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
X-mailer: Pegasus Mail for Windows (v2.54DE)
Message-ID: <2D6331E258B@HRZ1.hrz.tu-darmstadt.de>
Reply-To: djgpp-workers AT delorie DOT com

On Thu, 22 Feb 2001 23:56:22 +0100 (CET), Bruno Haible wrote:
> > Due to the great amount of name collsions in this package, I would
> > like to discuss the appropiate strategy for this package at
> > djgpp-workers first.
>
> I like the fnchange.lst solution. It confines the problem to a single
> file, and lets the Unix developers do their work without imposing
> unduly 8+3 restrictions on them.

On Fri, 23 Feb 2001 10:22:15 +0200, Eli Zaretskii wrote:
> > I like the fnchange.lst solution. It confines the problem to a single
> > file, and lets the Unix developers do their work without imposing
> > unduly 8+3 restrictions on them.
>
> With all due respect, I'd suggest to reconsider this.
[SNIP]

Before talking about the ranaming or not renaming issue, it should be noticed
that we are dealing with **two** different packages.
In gettext, there are only difficulties with the filename tests/xgettext-[1-9]
and tests/msgmerge-[1-5]. It can be seen that xgettext-[1-9] is mapped to xgettext
and msgmerge-[1-5] is mapped to msgmerge-. This are the only name conflicts in the
whole package. To resolve the conflict, Iwould suggest to rename the test scripts
according to the following list:
  gettext-1   gettext.1
  gettext-2   gettext.2
  msgcmp-1    msgcmp.1
  msgcmp-2    msgcmp.2
  msgfmt-1    msgfmt.1
  msgfmt-2    msgfmt.2
  msgfmt-3    msgfmt.3
  msgfmt-4    msgfmt.4
  msgmerge-1  msgmerge.1
  msgmerge-2  msgmerge.2
  msgmerge-3  msgmerge.3
  msgmerge-4  msgmerge.4
  msgmerge-5  msgmerge.5
  msgunfmt-1  msgunfmt.1
  xgettext-1  xgettext.1
  xgettext-2  xgettext.2
  xgettext-3  xgettext.3
  xgettext-4  xgettext.4
  xgettext-5  xgettext.5
  xgettext-6  xgettext.6
  xgettext-7  xgettext.7
  xgettext-8  xgettext.8
  xgettext-9  xgettext.9
I know that the list contains all test scripts. This is intentional.
IMHO, if *all* dashes are replaced by dots then the contents of the
tests directory look more homogeneous than if only xgettext-[1-9]
and msgmerge-[1-5] is renamed.
Anyway, this is only a suggestion.


Yesterday, I talk about libiconv and it looks bad.
FYI, this is a list of all the filenames that do not conform
to the DOS filename restriction. This means, they do not fit
into the 8.3 namespace.

The following files are not valid DOS file names:
libiconv-1.5.1/include/iconv.h.in - too many dots
libiconv-1.5.1/include/iconv.h.msvc-static - too many dots
libiconv-1.5.1/include/iconv.h.msvc-shared - too many dots
libiconv-1.5.1/tests/ARMSCII-8.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/CP932.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/CP950.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/EUC-JP.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/EUC-TW.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/ISO-IR-165.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/tests/BIG5HKSCS.IRREVERSIBLE.TXT - too many dots
libiconv-1.5.1/libcharset/tools/aix-3.2.5 - too many dots
libiconv-1.5.1/libcharset/tools/aix-4.1.5 - too many dots
libiconv-1.5.1/libcharset/tools/aix-4.2.0 - too many dots
libiconv-1.5.1/libcharset/tools/aix-4.3.2 - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.1.3 - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.1.90 - too many dots
libiconv-1.5.1/libcharset/tools/solaris-2.5.1 - too many dots
libiconv-1.5.1/libcharset/tools/sunos-4.1.4 - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6 - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6 - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f - too many dots
libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f - too many dots
libiconv-1.5.1/libcharset/include/libcharset.h.in - too many dots
libiconv-1.5.1/libcharset/include/libcharset.h.msvc-shared - too many dots
libiconv-1.5.1/libcharset/config.h.in - too many dots
libiconv-1.5.1/libcharset/config.h.msvc - too many dots
libiconv-1.5.1/lib/config.h.in - too many dots
libiconv-1.5.1/lib/config.h.msvc - too many dots

The following resolve to the same DOS file names:
ALL-CHAR       : libiconv-1.5.1/libcharset/tools/all-charsets
		 libiconv-1.5.1/libcharset/tools/all-charsets-X11
CHECK-ST       : libiconv-1.5.1/tests/check-stateful
		 libiconv-1.5.1/tests/check-stateless
CHECK-ST.BAT   : libiconv-1.5.1/tests/check-stateful.bat
		 libiconv-1.5.1/tests/check-stateless.bat
CHECK-ST.CMD   : libiconv-1.5.1/tests/check-stateful.cmd
		 libiconv-1.5.1/tests/check-stateless.cmd
CNS11643.H     : libiconv-1.5.1/lib/cns11643.h
		 libiconv-1.5.1/lib/cns11643_1.h
		 libiconv-1.5.1/lib/cns11643_2.h
		 libiconv-1.5.1/lib/cns11643_3.h
		 libiconv-1.5.1/lib/cns11643_inv.h
ENCODING.DEF   : libiconv-1.5.1/lib/encodings.def
		 libiconv-1.5.1/lib/encodings_aix.def
		 libiconv-1.5.1/lib/encodings_local.def
GENALIAS.C     : libiconv-1.5.1/lib/genaliases.c
		 libiconv-1.5.1/lib/genaliases2.c
GEORGIAN.H     : libiconv-1.5.1/lib/georgian_academy.h
		 libiconv-1.5.1/lib/georgian_ps.h
GEORGIAN.TXT   : libiconv-1.5.1/tests/Georgian-Academy.TXT
		 libiconv-1.5.1/tests/Georgian-PS.TXT
GLIBC-2.2-X    : libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6
		 libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f
ICONV.HMS      : libiconv-1.5.1/include/iconv.h.msvc-shared
		 libiconv-1.5.1/include/iconv.h.msvc-static
ISO-2022       : libiconv-1.5.1/tests/ISO-2022-CN-EXT-snippet
		 libiconv-1.5.1/tests/ISO-2022-CN-snippet
		 libiconv-1.5.1/tests/ISO-2022-JP-1-snippet
		 libiconv-1.5.1/tests/ISO-2022-JP-2-snippet
		 libiconv-1.5.1/tests/ISO-2022-JP-snippet
		 libiconv-1.5.1/tests/ISO-2022-KR-snippet
ISO-2022.UTF   : libiconv-1.5.1/tests/ISO-2022-CN-EXT-snippet.UTF-8
		 libiconv-1.5.1/tests/ISO-2022-CN-snippet.UTF-8
		 libiconv-1.5.1/tests/ISO-2022-JP-1-snippet.UTF-8
		 libiconv-1.5.1/tests/ISO-2022-JP-2-snippet.UTF-8
		 libiconv-1.5.1/tests/ISO-2022-JP-snippet.UTF-8
		 libiconv-1.5.1/tests/ISO-2022-KR-snippet.UTF-8
ISO-8859.TXT   : libiconv-1.5.1/tests/ISO-8859-1.TXT
		 libiconv-1.5.1/tests/ISO-8859-10.TXT
		 libiconv-1.5.1/tests/ISO-8859-13.TXT
		 libiconv-1.5.1/tests/ISO-8859-14.TXT
		 libiconv-1.5.1/tests/ISO-8859-15.TXT
		 libiconv-1.5.1/tests/ISO-8859-16.TXT
		 libiconv-1.5.1/tests/ISO-8859-2.TXT
		 libiconv-1.5.1/tests/ISO-8859-3.TXT
		 libiconv-1.5.1/tests/ISO-8859-4.TXT
		 libiconv-1.5.1/tests/ISO-8859-5.TXT
		 libiconv-1.5.1/tests/ISO-8859-6.TXT
		 libiconv-1.5.1/tests/ISO-8859-7.TXT
		 libiconv-1.5.1/tests/ISO-8859-8.TXT
		 libiconv-1.5.1/tests/ISO-8859-9.TXT
ISO2022_.H     : libiconv-1.5.1/lib/iso2022_cn.h
		 libiconv-1.5.1/lib/iso2022_cnext.h
		 libiconv-1.5.1/lib/iso2022_jp.h
		 libiconv-1.5.1/lib/iso2022_jp1.h
		 libiconv-1.5.1/lib/iso2022_jp2.h
		 libiconv-1.5.1/lib/iso2022_kr.h
ISO8859_.H     : libiconv-1.5.1/lib/iso8859_1.h
		 libiconv-1.5.1/lib/iso8859_10.h
		 libiconv-1.5.1/lib/iso8859_13.h
		 libiconv-1.5.1/lib/iso8859_14.h
		 libiconv-1.5.1/lib/iso8859_15.h
		 libiconv-1.5.1/lib/iso8859_16.h
		 libiconv-1.5.1/lib/iso8859_2.h
		 libiconv-1.5.1/lib/iso8859_3.h
		 libiconv-1.5.1/lib/iso8859_4.h
		 libiconv-1.5.1/lib/iso8859_5.h
		 libiconv-1.5.1/lib/iso8859_6.h
		 libiconv-1.5.1/lib/iso8859_7.h
		 libiconv-1.5.1/lib/iso8859_8.h
		 libiconv-1.5.1/lib/iso8859_9.h
ISOIR165.H     : libiconv-1.5.1/lib/isoir165.h
		 libiconv-1.5.1/lib/isoir165ext.h
LOCALE_C.C     : libiconv-1.5.1/libcharset/tools/locale_charset.c
		 libiconv-1.5.1/libcharset/tools/locale_codeset.c
MACROMAN.TXT   : libiconv-1.5.1/tests/MacRoman.TXT
		 libiconv-1.5.1/tests/MacRomania.TXT
MAC_ROMA.H     : libiconv-1.5.1/lib/mac_roman.h
		 libiconv-1.5.1/lib/mac_romania.h

There are two approaches IMHO:
a) Doing nothing.
   Nothing is changed, the package remains as it is. Then the package
   can be configured and compiled *more or less* out-of-the-box on win9x.
   This means LFN support *must* be available for configuring, compiling,
   testing and installing and users of msdos/freedos/opendos (only SFN
   support) will be excluded. Of course, a DJGPP port always consist of
   three zip files: binaries, docs and sources, so the DJGPP users will
   be able to use the port on plain DOS but they will not be able to
   change the sources and recompile the package.

b) A DJGPP specific solution.
   A djgpp directory must be created in libiconv-1.5.1. This directory will
   contain all the files needed to "patch" the sources on-the-fly while
   configuring.
   There will be three kind of files: fnchange.lst, config.bat and some
   sed scripts. The user that wants to compile libiconv-1.x.x.tar.gz
   out-of-the-box will have to use DJGPP's djtar program together with
   the provided fnchange.lst. djtar allows file renaming on-the-fly.
   This list (fnchange.lst) will contain all filenames that must be
   changed (old filename  new filename). After having unzipped the archive,
   the package must be configured for MSDOS/DJGPP. This will be done by
   running config.bat. This batch file will change all files that need
   to be changed using a serie of supplied sed scripts. Once again: the
   filename conflicts will be resolved by unzipping the archive in a
   DJGPP specific way and by modifing the sources accordingly. Of course,
   all this will *not* interfere with the way libiconv configures and
   compiles for other targets. And for a DJGPP user all this will happen
   behind the sceens.
   To resolve the name conflict, new directories are created while unzipping.
   Filenames like iso8895_XX.h resolve to the same filename iso8895_.h
   on plain DOS. This can be avoided by extracting this files into a new
   directory. Example:
     lib/iso8859_XX.h    become lib/ISO/8859_XX.h
     lib/iso2022_XXXX.h  become lib/ISO/2022_XXXX.h
     lib/isoir165XXX.h   become lib/ISO/ir165XXX.h
   All ISO files can be moved into a new ISO directory.
   The same applies to the cns11643XX.h, mac_XXXXXX.h, encondings_XXX.def
   and other files more:
     lib/cns11643_XXX.h  become lib/CNS/11643_XXX.h
     lib/mac_XXXXXXXX.h  become lib/MAC/XXXXXXXXX.h

   Once again: there are much more files that need to be treated. The above
   are only examples of what must be done.
   Of course, the sources and Makefiles must be modified to reflect this new
   directory structure accordingly. The same applies to the test directory.

I have no preferences. I have patches for both solutions. Of course,
if someone knows a better solution, please let me know and I will make a
new patch.


On Fri, 23 Feb 2001 10:11:02 +0200, Eli Zaretskii wrote:
>           (usage) [O_BINARY]: Print --binary option.
>
> I probably missed this when I read your previous set of patches.
>
> Why is the --binary option needed?  Why cannot the files be always
> read and written in binary mode?

I would agree. The default operation mode of iconv.exe should be with
O_BINARY on WinDos. It is worth to be noticed that the testsuit of libiconv
does *not* work properly on WinDos due to the default O_TEXT mode reading
and writting.
I solved the difficulty by adding the following snippet to check-stateful

[SNIP]
# For systems that distinguish between text and binary I/O
# the binary mode of iconv must be selected and for
# systems with severe filename restrictions allow for
# an alternate filename.
UNAME=${UNAME-`uname 2>/dev/null`}
case X$UNAME in
  *-DOS) MODE='--binary'
         filename=`echo "$charset" | sed "s|ISO-|ISO/|;s|2022-|2022|"` ;;
  *)     MODE=''
         filename="$charset" ;;
esac
../src/iconv $MODE -f "$charset" -t UTF-8 < "${srcdir}"/"$filename"-snippet > tmp-snippet
[SNIP]

Anyway, this must be decided by Bruno.

Regards,
Guerrero, Juan Manuel

- Raw text -


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