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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@gentoo.org mailing list
>
>
--
gentoo-user@gentoo.org mailing list
