Re: [gentoo-user] Fwd: FontForge needs conversion from ISO-8859-1 to UCS2 - iconv (glibc-2.3.5-r2) does not support it on amd64

[Michael [Plouj] Ploujnikov]

Could this be related to the fact that for my normal user I see:
$ echo $GCONV_PATH
/usr/lib32/gconv

(root doesn't have that env var set at all)

On 4/26/06, Michael [Plouj] Ploujnikov <ploujj@×××××.com> wrote:
> After doing:
> # mv lib32{,-bak}
> # ln -s lib64 lib32
>
> I saw the following results:
>
> $ iconv --from-code ISO-8859-1 --to-code UCS2 </dev/null
> $ iconv --from-code ISO-8859-1 --to-code UCS-2 </dev/null
> $ iconv --from-code ISO-8859-1 --to-code UCS-2-INTERNAL </dev/null
> iconv: conversion to `UCS-2-INTERNAL' is not supported
> $ iconv --from-code ISO-8859-1 --to-code "ISO-10646/UCS2" </dev/null
> $ iconv --from-code ISO-8859-1 --to-code "UNICODE" </dev/null
>
> Assuming that no output means the conversions suceed shows that it
> does have something to do with iconv originally loading a wrong
> module. So it seems that your hypothesis is right. I thought of this
> before, when I was looking at the gconv/ contents but I didn't
> actually try it because the gconv-modules file syntax confused me. I
> thought iconv was not finding an appropriate module for conversion in
> this file.
>
> Also, FF ran fine (configured with iconv) once I forced the 64bit
> directory to be used
>
> On 4/26/06, Hans-Werner Hilse <hilse@×××.de> wrote:
> > from that output:
> > ---snip
> > open("/usr/lib32/gconv/UNICODE.so", O_RDONLY) = 4
> > read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \5\0\000"..., 640) = 640
> > close(4)                                = 0
> > open("/usr/lib32/gconv/ISO8859-1.so", O_RDONLY) = 4
> > read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\4\0"..., 640) = 640
> > close(4)                                = 0
> > ---snip
> >
> > So it opens a file, reads 640 bytes and closes it. Note the "/lib32".
> > Now this is my output, 32bit platform:
> >
> > ---snip
> > open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 3
> > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\4\0"..., 512) = 512
> > fstat64(3, {st_mode=S_IFREG|0755, st_size=9720, ...}) = 0
> > mmap2(NULL, 12316, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7de4000
> > mmap2(0xb7de6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7de6000
> > ---snip
> >
> > So after reading the first 512 bytes, it mmap's a code section and a
> > data section into address space. Dynamic loading, I'd say (without
> > further debugging). So this seems to fail for you and I think the
> > "lib32" indicates that the 64bit glibc errorneously tries to load the
> > wrong modules for iconv.
> >
> > Maybe you can temporarily move the lib32/gconv dir and soft link the
> > lib64/gconf in place of it to verify my assumption (it should work
> > then, but this is obviously not a solution as it will break 32bit
> > environment). You might want to file a bug into gentoo's bugzilla
> > (after searching for an existing one, of course).
> >
> > > By looking at /usr/lib{64,32}/gconv/gconv-modules (wich are identical)
> > > it looks like there really isn't any conversion specified from
> > > ISO-8859-1 to any other code.
> >
> > Strange. Mine has:
> > ---snip
> > module  ISO-8859-1//            INTERNAL                ISO8859-1       1
> > ---snip
> >
> > (whatever that means)
> >
> > -hwh
> > --
> > gentoo-user@g.o mailing list
> >
> >
>

-- 
gentoo-user@g.o mailing list