bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: z/OS, iconv, and gperf


From: Bruno Haible
Subject: Re: z/OS, iconv, and gperf
Date: Sat, 21 Dec 2019 06:49:33 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-166-generic; KDE/5.18.0; x86_64; ; )

Hi Daniel,

> > Thanks. From this, I think we can equate the following vendor names
> > with GNU canonical names:
> 
> Is there a good test to ensure that the conversions are as expected? I
> wouldn't put it past IBM to use a strange variant of some of these otherwise-
> familiar encodings...

Oh, certainly many of the IBM-nnn encodings are variants of what Microsoft
and the rest of the world do regarding codepage nnn. Find an extensive
comparison at https://haible.de/bruno/charsets/conversion-tables/index.html .

You find the tools to extract the conversion tables and compare them here:
https://haible.de/bruno/charsets/conversion-tables/tools.html

> > Omitting identical names on both sides (e.g. BIG5 BIG5), I arrive at
> > the two attached patches.
> 
> Git 3f7d8da2 gives me this build error:
> 
> make[3]: Entering directory `/tmp/gnulib-build/gllib'
> source='/tmp/testdir/gllib/iconv_open.c' object='iconv_open.o' libtool=no \
> DEPDIR=.deps depmode=aix /bin/sh /tmp/testdir/build-aux/depcomp \
> xlc-wrap -DHAVE_CONFIG_H -I. -I/tmp/testdir/gllib -I..  
> -DGNULIB_STRICT_CHECKING=1 -D_UNIX95_THREADS -D_XOPEN_SOURCE=600 -DNSIG=39 
> -qhaltonmsg=CCN3296  -g -q64 -qfloat=ieee -qlanglvl=extc99 -qenumsize=4  -c 
> -o iconv_open.o /tmp/testdir/gllib/iconv_open.c
> ERROR CCN3205 /tmp/testdir/gllib/iconv_open-zos.h:29    "gperf generated 
> tables don't work with this execution character set. Please report a bug to 
> <address@hidden>."
> CCN0793(I) Compilation failed for file /tmp/testdir/gllib/iconv_open.c.  
> Object file not created.
> make[3]: *** [iconv_open.o] Error 12
> 
> Normally, everything builds using EBCDIC on this system. (There are ways
> of compiling ASCII source, but that's not the usual way of working.)
> 
> There isn't a way to compile gperf tables in an encoding-agnostic
> manner?

No. gperf works by using character values as indices into arrays; the
arrays are filled by gperf at code generation time.

Can you experiment with the pragmas to resolve this? For this, you
best take the gperf source distribution, remove the part that emits
the error message in gperf/src/output.cc:2103, and then work with
"make check" to get things working.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]