Opened 8 months ago

Closed 7 months ago

#68356 closed defect (fixed)

libiconv @1.17_0: conversion to UTF8 unsupported

Reported by: eric-j-ason Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc:
Port: libiconv

Description

Converting to or from "UTF8" yields an error, but "UTF-8" works. This is in contrast to other versions of iconv.

iconv from MacPorts gives an error:

$ echo hello | /opt/local/bin/iconv --to-code UTF8
iconv: conversion to UTF8 unsupported
iconv: try '/opt/local/bin/iconv -l' to get the list of supported encodings
$ /opt/local/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8'
UTF-8
UTF-8-MAC UTF8-MAC
$ /opt/local/bin/iconv --version
iconv (GNU libiconv 1.17)
Copyright (C) 2000-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

iconv from MacOS gives no error:

$ echo hello | /usr/bin/iconv --to-code UTF8
hello
$ /usr/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8'
UTF-8 UTF8
UTF-8-MAC UTF8-MAC
$ /usr/bin/iconv --version
iconv (GNU libiconv 1.11)
Copyright (C) 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible.

iconv on Debian gives no error:

$ echo hello | /usr/bin/iconv --to-code UTF8
hello
$ /usr/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8'
ISO-10646/UTF-8/
ISO-10646/UTF8/
UTF-8//
UTF8//
$ /usr/bin/iconv --version
iconv (Debian GLIBC 2.31-13+deb11u7) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.

This bug was noticed because pdfjam uses iconv and stopped working:

https://github.com/rrthomas/pdfjam/blob/v3.08/bin/pdfjam#L954 https://github.com/rrthomas/pdfjam/blob/v3.08/bin/pdfjam#L975

Change History (5)

comment:1 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign removed
Owner: set to ryandesign
Status: newassigned

This has come up before, and it was decided not to support this. See #57886 and the linked mailing list thread for more info.

comment:2 Changed 8 months ago by eric-j-ason

That was an interesting e-mail conversation. Very well researched by the submitter, with links to specific source code lines in many implementations and a survey of standards. It's amazing that there are so many different implementations of the thing!

Anyway, should pdfjam (which uses "utf8") then be considered to be where the bug resides?

Also, do you have any idea of how this problem has arisen now? The bug report #57886 is five years old, yet for me it must have stopped working only in the last few months or so.

comment:3 in reply to:  2 ; Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to eric-j-ason:

Anyway, should pdfjam (which uses "utf8") then be considered to be where the bug resides?

I see you already submitted a fix to the developer and they accepted it and released a new version and you filed #68365 to update MacPorts pdfjam to this version.

Also, do you have any idea of how this problem has arisen now? The bug report #57886 is five years old, yet for me it must have stopped working only in the last few months or so.

Looks like the code that started using iconv (with utf8) was added to pdfjam in November 2021 but it was not included in a release until version 3.0.4 in May 2023. MacPorts updated to this version in August 2023 so you would not have seen the problem with pdfjam before then.

comment:4 in reply to:  3 Changed 8 months ago by eric-j-ason

Replying to ryandesign:

I see you already submitted a fix to the developer and they accepted it and released a new version and you filed #68365 to update MacPorts pdfjam to this version.

Yes, that seemed to be where to fix it. Counting on that the port for pdfjam will be updated, I'm thinking that this issue for libiconv can be closed. (I don't think I can do that myself, though, right?)

Looks like the code that started using iconv (with utf8) was added to pdfjam in November 2021 but it was not included in a release until version 3.0.4 in May 2023. MacPorts updated to this version in August 2023 so you would not have seen the problem with pdfjam before then.

That explains it. Thank you!

comment:5 Changed 7 months ago by breun (Nils Breunese)

Resolution: fixed
Status: assignedclosed

In 909795b3d2cbe41acf616d5fe0c956b6e3647d2a/macports-ports (master):

pdfjam: update to 3.09

Closes: #68365
Closes: #68356

Note: See TracTickets for help on using tickets.