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
This is fixed in glibc-2.3.6-r4 and glibc-2.4-r2 now: https://bugs.gentoo.org/show_bug.cgi?id=131386 -- gentoo-user@gentoo.org mailing list
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
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//INTERNALISO8859-1 1
---snip
(whatever that means)
-hwh
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
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
Ignore the $GCONV_PATH bit. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Fwd: FontForge needs conversion from ISO-8859-1 to UCS2 - iconv (glibc-2.3.5-r2) does not support it on amd64
This started when I found out that FontForge (FF) does not want to run with Gentoo's iconv: http://bugs.gentoo.org/show_bug.cgi?id=124998 The FF developer told me: According to the $ iconv --list you sent (http://plouj.sh.nu/iconvlist) both UCS2 and ISO-8859-1 are supported by your iconv. Yet attempting to convert one to the other fails. FF requires this conversion to work before it will start. Although FF seems to work now if compiled --without-iconv, I would like to know why this conversion is not working on my system. Here is what happens if I type: $ iconv --from-code ISO-8859-1 --to-code UCS2 /dev/null iconv: conversion from `ISO-8859-1' is not supported $ iconv --from-code ISO-8859-1 --to-code UCS-2 /dev/null iconv: conversion from `ISO-8859-1' is not supported $ iconv --from-code ISO-8859-1 --to-code UCS-2-INTERNAL /dev/null iconv: conversion from `ISO-8859-1' and to `UCS-2-INTERNAL' are not supported $ iconv --from-code ISO-8859-1 --to-code ISO-10646/UCS2 /dev/null iconv: conversion from `ISO-8859-1' is not supported $ iconv --from-code ISO-8859-1 --to-code UNICODE /dev/null iconv: conversion from `ISO-8859-1' and to `UNICODE' are not supported Is there a way to make this conversion work? What is required? Is this somehow related to the locales which I have installed? How can I find out what kind of conversions would work on my system? Is this a known bug? My locales as configured from the time Gentoo was installed: $ cat /etc/locales.build en_US/ISO-8859-1 en_US.UTF-8/UTF-8 If there is a more appropriate gentoo mailing list for this, please direct me there. Thank you for your in advance. -- gentoo-user@gentoo.org mailing list
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
Hi, On Wed, 26 Apr 2006 11:43:09 -0400 Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote: Although FF seems to work now if compiled --without-iconv, I would like to know why this conversion is not working on my system. Here is what happens if I type: [...] Hm. Works for me. And this hasn't to do with locales (at least, it shouldn't). What are the USE flags for your glibc? Is nls enabled? -hwh -- gentoo-user@gentoo.org mailing list
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
This is how my glibc is currently installed: sys-libs/glibc-2.3.5-r2 -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls +nptl +nptlonly -pic -profile (-selinux) +userlocales Did you say that those conversions work for you on amd64? On 4/26/06, Hans-Werner Hilse [EMAIL PROTECTED] wrote: Hi, On Wed, 26 Apr 2006 11:43:09 -0400 Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote: Although FF seems to work now if compiled --without-iconv, I would like to know why this conversion is not working on my system. Here is what happens if I type: [...] Hm. Works for me. And this hasn't to do with locales (at least, it shouldn't). What are the USE flags for your glibc? Is nls enabled? -hwh -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
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
Hi, On Wed, 26 Apr 2006 12:42:09 -0400 Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote: Did you say that those conversions work for you on amd64? Ah, I'm seeing it now in the subject. No, I was quietly assuming you're talking about x86. I don't have an amd64 machine at hand, so I can't help here... glibc's USE flags seem to be all right for me. Maybe other people can test it on amd64. What I noticed when strace'ing iconv, though, was that it accesses some files in /usr/lib/gconv. Does this directory exist on amd64? You might want to run strace iconv ..., too, maybe the error is displayed there. -hwh -- gentoo-user@gentoo.org mailing list
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
Here is the strace output: http://plouj.sh.nu/straceiconv
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.
--
gentoo-user@gentoo.org mailing list
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
Hi,
On Wed, 26 Apr 2006 14:09:18 -0400
Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote:
Here is the strace output: http://plouj.sh.nu/straceiconv
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//INTERNALISO8859-1 1
---snip
(whatever that means)
-hwh
--
gentoo-user@gentoo.org mailing list
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
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//INTERNALISO8859-1 1
---snip
(whatever that means)
-hwh
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
