On Fri, 2019 Dec 20 03:19-05:00, Bruno Haible wrote: > > 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... > 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 <bug-gp...@gnu.org>." 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? --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman.
