Bug#1018881: glibc: iconv not working properly on m68k and sh4
Hi! On 9/1/22 23:59, Aurelien Jarno wrote: The problem is that the /usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow truncated for the glibc 2.34 build. Running iconvconfig by hand to generate it fixes the issue. It seems to be the right size for the glibc 2.35 build. Yes, running iconvconfig manually fixes the problem indeed. Now I just need to figure out why the file is truncated in the first place. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Only the japanese locales are not working? Are they missing? On Thu, Sep 1, 2022 at 6:45 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Source: glibc > Version: 2.34-7 > Severity: normal > User: debian-sup...@lists.debian.org > Usertags: m68k sh4 > X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org > > Hello! > > iconv stopped working on m68k and sh4 starting with glibc 2.34 and > I have no clue why. The issue can be reproduced on real hardware > qemu-user and qemu-system. > > The problem becomes visible when the configure script of the gettext > package is being run on the affected architectures: > > checking for iconv... yes > checking for working iconv... no > checking for iconv declaration... > extern size_t iconv (iconv_t cd, char * *inbuf, size_t > *inbytesleft, char * *outbuf, size_t *outbytesleft); > checking for inttypes.h... (cached) yes > checking for limits.h... (cached) yes > > The configure script runs a small program which I have extracted and > attached to this bug report as iconv.c. > > Running it on amd64 returns a zero exit code: > > (sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc > (sid-amd64-sbuild)root@nofan:/# ./iconv > (sid-amd64-sbuild)root@nofan:/# echo $? > 0 > (sid-amd64-sbuild)root@nofan:/# > > On m68k and sh4, the exit code is 16 which is why the above configure > check fails: > > glaubitz@tirpitz:~$ uname -a > Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 > 21:10:17 CET 2021 sh4a GNU/Linux > glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc > glaubitz@tirpitz:~$ ./iconv > glaubitz@tirpitz:~$ echo $? > 16 > glaubitz@tirpitz:~$ > > I have run out of ideas why iconv fails, so I was wondering whether this > might > be a packaging issue. I have found a similar iconv issue being discussed > on a > Fedora mailing list where the cause was iconv data being moved out of the > main > glibc packages [1]. > > Maybe we have a similar problem in Debian which manifests on m68k and sh4 > only > due to some reverse dependencies being out of date? > > Thanks, > Adrian > > > [1] > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Hi, On 2022-09-01 12:41, John Paul Adrian Glaubitz wrote: > Source: glibc > Version: 2.34-7 > Severity: normal > User: debian-sup...@lists.debian.org > Usertags: m68k sh4 > X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org > > Hello! > > iconv stopped working on m68k and sh4 starting with glibc 2.34 and > I have no clue why. The issue can be reproduced on real hardware > qemu-user and qemu-system. > > The problem becomes visible when the configure script of the gettext > package is being run on the affected architectures: > > checking for iconv... yes > checking for working iconv... no > checking for iconv declaration... > extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, > char * *outbuf, size_t *outbytesleft); > checking for inttypes.h... (cached) yes > checking for limits.h... (cached) yes > > The configure script runs a small program which I have extracted and > attached to this bug report as iconv.c. > > Running it on amd64 returns a zero exit code: > > (sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc > (sid-amd64-sbuild)root@nofan:/# ./iconv > (sid-amd64-sbuild)root@nofan:/# echo $? > 0 > (sid-amd64-sbuild)root@nofan:/# > > On m68k and sh4, the exit code is 16 which is why the above configure > check fails: > > glaubitz@tirpitz:~$ uname -a > Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17 > CET 2021 sh4a GNU/Linux > glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc > glaubitz@tirpitz:~$ ./iconv > glaubitz@tirpitz:~$ echo $? > 16 > glaubitz@tirpitz:~$ The problem is that the /usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow truncated for the glibc 2.34 build. Running iconvconfig by hand to generate it fixes the issue. It seems to be the right size for the glibc 2.35 build. > I have run out of ideas why iconv fails, so I was wondering whether this might > be a packaging issue. I have found a similar iconv issue being discussed on a > Fedora mailing list where the cause was iconv data being moved out of the main > glibc packages [1]. > > Maybe we have a similar problem in Debian which manifests on m68k and sh4 only > due to some reverse dependencies being out of date? Not his is unrelated, we haven't changed that part of the packaging. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1018881: glibc: iconv not working properly on m68k and sh4
Source: glibc
Version: 2.34-7
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: m68k sh4
X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org
Hello!
iconv stopped working on m68k and sh4 starting with glibc 2.34 and
I have no clue why. The issue can be reproduced on real hardware
qemu-user and qemu-system.
The problem becomes visible when the configure script of the gettext
package is being run on the affected architectures:
checking for iconv... yes
checking for working iconv... no
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft,
char * *outbuf, size_t *outbytesleft);
checking for inttypes.h... (cached) yes
checking for limits.h... (cached) yes
The configure script runs a small program which I have extracted and
attached to this bug report as iconv.c.
Running it on amd64 returns a zero exit code:
(sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc
(sid-amd64-sbuild)root@nofan:/# ./iconv
(sid-amd64-sbuild)root@nofan:/# echo $?
0
(sid-amd64-sbuild)root@nofan:/#
On m68k and sh4, the exit code is 16 which is why the above configure
check fails:
glaubitz@tirpitz:~$ uname -a
Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17
CET 2021 sh4a GNU/Linux
glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc
glaubitz@tirpitz:~$ ./iconv
glaubitz@tirpitz:~$ echo $?
16
glaubitz@tirpitz:~$
I have run out of ideas why iconv fails, so I was wondering whether this might
be a packaging issue. I have found a similar iconv issue being discussed on a
Fedora mailing list where the cause was iconv data being moved out of the main
glibc packages [1].
Maybe we have a similar problem in Debian which manifests on m68k and sh4 only
due to some reverse dependencies being out of date?
Thanks,
Adrian
> [1]
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
#include
#include
#define ICONV_CONST
int main() {
int result = 0;
/* Test against AIX 5.1 bug: Failures are not distinguishable from successful
returns. */
{
iconv_t cd_utf8_to_88591 = iconv_open ("ISO8859-1", "UTF-8");
if (cd_utf8_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\342\202\254"; /* EURO SIGN */
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_utf8_to_88591,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
if (res == 0)
result |= 1;
iconv_close (cd_utf8_to_88591);
}
}
/* Test against Solaris 10 bug: Failures are not distinguishable from
successful returns. */
{
iconv_t cd_ascii_to_88591 = iconv_open ("ISO8859-1", "646");
if (cd_ascii_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\263";
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_ascii_to_88591,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
if (res == 0)
result |= 2;
iconv_close (cd_ascii_to_88591);
}
}
/* Test against AIX 6.1..7.1 bug: Buffer overrun. */
{
iconv_t cd_88591_to_utf8 = iconv_open ("UTF-8", "ISO-8859-1");
if (cd_88591_to_utf8 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\304";
static char buf[2] = { (char)0xDE, (char)0xAD };
ICONV_CONST char *inptr = input;
size_t inbytesleft = 1;
char *outptr = buf;
size_t outbytesleft = 1;
size_t res = iconv (cd_88591_to_utf8,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
if (res != (size_t)(-1) || outptr - buf > 1 || buf[1] != (char)0xAD)
result |= 4;
iconv_close (cd_88591_to_utf8);
}
}
#if 0 /* This bug could be worked around by the caller. */
/* Test against HP-UX 11.11 bug: Positive return value instead of 0. */
{
iconv_t cd_88591_to_utf8 = iconv_open ("utf8", "iso88591");
if (cd_88591_to_utf8 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\304rger mit b\366sen B\374bchen
ohne Augenma\337";
char buf[50];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_88591_to_utf8,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
