[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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-superh@lists.debian.org
> Usertags: m68k sh4
> X-Debbugs-Cc: debian-68k@lists.debian.org,debian-superh@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
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: