1 |
After doing: |
2 |
# mv lib32{,-bak} |
3 |
# ln -s lib64 lib32 |
4 |
|
5 |
I saw the following results: |
6 |
|
7 |
$ iconv --from-code ISO-8859-1 --to-code UCS2 </dev/null |
8 |
$ iconv --from-code ISO-8859-1 --to-code UCS-2 </dev/null |
9 |
$ iconv --from-code ISO-8859-1 --to-code UCS-2-INTERNAL </dev/null |
10 |
iconv: conversion to `UCS-2-INTERNAL' is not supported |
11 |
$ iconv --from-code ISO-8859-1 --to-code "ISO-10646/UCS2" </dev/null |
12 |
$ iconv --from-code ISO-8859-1 --to-code "UNICODE" </dev/null |
13 |
|
14 |
Assuming that no output means the conversions suceed shows that it |
15 |
does have something to do with iconv originally loading a wrong |
16 |
module. So it seems that your hypothesis is right. I thought of this |
17 |
before, when I was looking at the gconv/ contents but I didn't |
18 |
actually try it because the gconv-modules file syntax confused me. I |
19 |
thought iconv was not finding an appropriate module for conversion in |
20 |
this file. |
21 |
|
22 |
Also, FF ran fine (configured with iconv) once I forced the 64bit |
23 |
directory to be used |
24 |
|
25 |
On 4/26/06, Hans-Werner Hilse <hilse@×××.de> wrote: |
26 |
> from that output: |
27 |
> ---snip |
28 |
> open("/usr/lib32/gconv/UNICODE.so", O_RDONLY) = 4 |
29 |
> 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 |
30 |
> close(4) = 0 |
31 |
> open("/usr/lib32/gconv/ISO8859-1.so", O_RDONLY) = 4 |
32 |
> 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 |
33 |
> close(4) = 0 |
34 |
> ---snip |
35 |
> |
36 |
> So it opens a file, reads 640 bytes and closes it. Note the "/lib32". |
37 |
> Now this is my output, 32bit platform: |
38 |
> |
39 |
> ---snip |
40 |
> open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 3 |
41 |
> 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 |
42 |
> fstat64(3, {st_mode=S_IFREG|0755, st_size=9720, ...}) = 0 |
43 |
> mmap2(NULL, 12316, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7de4000 |
44 |
> mmap2(0xb7de6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7de6000 |
45 |
> ---snip |
46 |
> |
47 |
> So after reading the first 512 bytes, it mmap's a code section and a |
48 |
> data section into address space. Dynamic loading, I'd say (without |
49 |
> further debugging). So this seems to fail for you and I think the |
50 |
> "lib32" indicates that the 64bit glibc errorneously tries to load the |
51 |
> wrong modules for iconv. |
52 |
> |
53 |
> Maybe you can temporarily move the lib32/gconv dir and soft link the |
54 |
> lib64/gconf in place of it to verify my assumption (it should work |
55 |
> then, but this is obviously not a solution as it will break 32bit |
56 |
> environment). You might want to file a bug into gentoo's bugzilla |
57 |
> (after searching for an existing one, of course). |
58 |
> |
59 |
> > By looking at /usr/lib{64,32}/gconv/gconv-modules (wich are identical) |
60 |
> > it looks like there really isn't any conversion specified from |
61 |
> > ISO-8859-1 to any other code. |
62 |
> |
63 |
> Strange. Mine has: |
64 |
> ---snip |
65 |
> module ISO-8859-1// INTERNAL ISO8859-1 1 |
66 |
> ---snip |
67 |
> |
68 |
> (whatever that means) |
69 |
> |
70 |
> -hwh |
71 |
> -- |
72 |
> gentoo-user@g.o mailing list |
73 |
> |
74 |
> |
75 |
|
76 |
-- |
77 |
gentoo-user@g.o mailing list |