What are iconv differences in OpenWrt?

For Developers
1

I'm trying to update tvheadend to master branch. I get an error:
main: iconv() routine is not working properly ((null)), aborting!
This check was introduced here:

And some iconv discussion here:
https://tvheadend.org/issues/4940

I understand that OpenWrt built without "Full language support" will include a stub (or is it musl iconv?) instead of standard iconv.

Can someone explain OpenWrt iconv functionality?
What is the expected behaviour when a package uses default OpenWrt iconv? Is null expected for that test?

Second question:
What should I do if newer versions of tvheadend won't work without full iconv?
According to this email, I should add DEPENDS:=@BUILD_NLS, and the tvheadend package will no longer be visible unless "Full language support" is selected. I think that also means it won't be built and made available from official repo for opkg install.

2

Yes, a failure is expected in this case. Apparently they want to convert utf-8 into ascii (removing accents, transliterate) which the OpenWrt intl stubs cannot really handle since such conversions require huge mapping tables which would take up a lot of space.

2 Likes
3

Thank you for your reply, but I need more details.

What is the expected result of the OpenWrt stub for that string?

  • Null / error?
  • Empty string?
  • Ascii 32-127 and some generic replacement for any char that is not in that range?
  • String as it is?

I'm asking because the test currently used allows a string with ascii 32-127 and question marks for everything else and yet it still fails.

The latest version of that test is this:

  const char *charset = intlconv_charset_id("ASCII", 1, 1);
  char *s = intlconv_utf8safestr(charset, "ŽluťoučkýKůň", 128);
  if (s == NULL ||
      (strcmp(s, "ZlutouckyKun") &&
       strcmp(s, "Zlutouck'yKun") &&
       strcmp(s, "?lu?ou?k?K??"))) {
    tvherror(LS_MAIN, "iconv() routine is not working properly (%s), aborting!", s);
    tvh_safe_usleep(2000000);
    abort();
4

The UTF-8->ASCII Codec in the stub will map any byte >= 0x80 to (wchar_t)0xfffe. Not sure if it is actually put as (char)0xff, (char)0xfe into the output buffer or whether it is clamped to (char)0xff. Can check more thoroughly when I am near a PC again.

I agree that it should use ? as replacement char though.

5

Agreed. 0xff is empty space only in cp437. It's a printable national character in all iso8859-x encodings.

This doesn't solve the mistery of that null, but it gives me a place to start.
Thanks.

6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.