Hi Jason,
At 11.23 25/08/2006 +0530, Jason Stewart wrote:
Hi David,
On 8/24/06, David Cargill <[EMAIL PROTECTED]> wrote:
Hi Jason,
I ran into a problem on some Linux platforms where the build defaulted to
using the GUNIconv transcoder. I updated packageBinaries.pl to specify
--enable-transcoder-iconv and that fixed the problem. Maybe try specifying
--enable-transcoder-iconv and see if that works.
I looked at the Iconv transcoder code - and it indicated that it
didn't provide a *real* transcoding service the comment in the code
says:
This is a minimalist transcoding service, that only supports a local
default transcoder. All named encodings return zero as a failure...
That won't work for Perl - I need a UTF-8 transcoder...
Alby - what is the big-endian problem in IconvGNU? If I could I would
put my machine on the 'net and let you play with it - but I'm behind a
firewall here...
My doubts come from this encoding table in the IconvGNUTransService.cpp:
static const IconvGNUEncoding gIconvGNUEncodings[] = {
{ "UCS-2LE", 2, LITTLE_ENDIAN },
{ "ucs-2-internal", 2, LITTLE_ENDIAN },
{ NULL, 0, 0 }
};
The last entry is LITTLE_ENDIAN, but the description for the field is
unsigned int fUBO; // byte order, relative to the host
Being "relative to the host", I think it should be BYTE_ORDER. But
it's just a guess, as I haven't tested on a big-endian machine (yet,
I could be able to do that today).
If you have time to test it now, let me know if this works.
Thanks,
Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
