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

Bug#1018881: marked as done (glibc: iconv not working properly on m68k and sh4)



Your message dated Fri, 14 Jul 2023 18:25:10 +0200
with message-id <ZLF25u8IL9vGxQ7/@aurel32.net>
and subject line Re: Bug#1018881: glibc: iconv not working properly on m68k and sh4
has caused the Debian Bug report #1018881,
regarding glibc: iconv not working properly on m68k and sh4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1018881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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:~$

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/devel@lists.fedoraproject.org/message/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
#include <iconv.h>
#include <string.h>

#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);
        if ((int)res > 0)
          result |= 8;
        iconv_close (cd_88591_to_utf8);
      }
  }
#endif
  /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
     provided.  */
  {
    /* Try standardized names.  */
    iconv_t cd1 = iconv_open ("UTF-8", "EUC-JP");
    /* Try IRIX, OSF/1 names.  */
    iconv_t cd2 = iconv_open ("UTF-8", "eucJP");
    /* Try AIX names.  */
    iconv_t cd3 = iconv_open ("UTF-8", "IBM-eucJP");
    /* Try HP-UX names.  */
    iconv_t cd4 = iconv_open ("utf8", "eucJP");
    if (cd1 == (iconv_t)(-1) && cd2 == (iconv_t)(-1)
        && cd3 == (iconv_t)(-1) && cd4 == (iconv_t)(-1))
      result |= 16;
    if (cd1 != (iconv_t)(-1))
      iconv_close (cd1);
    if (cd2 != (iconv_t)(-1))
      iconv_close (cd2);
    if (cd3 != (iconv_t)(-1))
      iconv_close (cd3);
    if (cd4 != (iconv_t)(-1))
      iconv_close (cd4);
  }
  return result;
}

--- End Message ---
--- Begin Message ---
Hi,

On 2022-09-04 08:03, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 9/2/22 18:43, Aurelien Jarno wrote:
> > I ran a build on mitchy.debian.net and the file is correctly generated.
> > Is there anything different on the buildds?
> 
> The buildds use qemu-user while mitchy uses qemu-system. The issue might be
> a result of the getdents issue in glibc [1]. I have uploaded a glibc package with
> the patch set included to unreleased in any case.

The issue seems rather link to a buildd issue than a glibc issue, and
seems to have disappeared. Let's close the bug.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

--- End Message ---

Reply to: