Bug 204770 - converters/libiconv r398996 patch breaks libidn
Summary: converters/libiconv r398996 patch breaks libidn
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gnome (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-23 19:58 UTC by wxl
Modified: 2018-01-16 16:02 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wxl 2015-11-23 19:58:04 UTC
I have a script that runs weekly and uses mutt to mail out a report. This worked flawlessly until this weekend when I started getting IDN errors. Since neither mutt nor libidn had changed since the last successful run, I checked backwards to see all the relevant dependencies that had changes and found libiconv.
Comment 1 Koop Mast freebsd_committer freebsd_triage 2015-11-23 22:28:38 UTC
Can you supply more info what exactly goes wrong?
Comment 2 wxl 2015-11-24 00:13:27 UTC
Specifically, mutt complains about a non-intentional hostname not being properly internationalized:
Bad IDN in "from": 'jeeves.bf-internal.com'

Re-compiling without IDN support solves the problem. Thus, the problem lies in libidn. However, since the last successful run, libidn had not changed, so it's a dependency of libidn that's changed. The only one that I could find that has changed is libiconv. 

I recognize this may be a logical error, but I'm inclined to believe that reporting an error can, at worst, lead to refiling a report where it properly belongs. However, nothing gets changed if it doesn't get reported at all.

So here's what I do know:

mutt's compose.c includes this aforementioned error:
http://dev.mutt.org/hg/mutt/file/e635ce43b001/compose.c#l609
which calls on mutt_idna.c:
hhttp://dev.mutt.org/hg/mutt/file/e635ce43b001/mutt_idna.c
the heavy lifting there is using idna_to_unicode_8z8z() and idna_to_ascii_8z().

And that's about where I get lost. libidn confusingly says iconv isn't strictly required:
http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=blob;f=configure.ac;h=dc340dab04082e23e364f0edbffcd90a4920e00f;hb=b45deaf855dfec2bb1d13f5bf306829e62f35ade#l59
and yet it is.

So I'm hoping someone with a little more intimiacy might be able to help more. Thanks.
Comment 3 Tijl Coosemans freebsd_committer freebsd_triage 2015-11-24 09:06:36 UTC
What version of FreeBSD do you use?  Also, can you post the output of this command:
readelf -s /usr/local/lib/libidn.so | grep iconv
Comment 4 wxl 2015-11-24 17:56:45 UTC
Ooops! FreeBSD 10.1. Sorry I missed that.

For that matter, here's relevant pkg versions:
libiconv-1.14_9                    =
libidn-1.31                        =
zh-mutt-1.5.24                     =

Here's the libiconv symbols in libidn:
     5: 0000000000000000    93 FUNC    GLOBAL DEFAULT  UND __bsd_iconv@FBSD_1.3 (4)
    11: 0000000000000000     9 FUNC    GLOBAL DEFAULT  UND __bsd_iconv_open@FBSD_1.3 (4)
    20: 0000000000000000    41 FUNC    GLOBAL DEFAULT  UND __bsd_iconv_close@FBSD_1.3 (4)
Comment 5 Walter Schwarzenfeld freebsd_triage 2018-01-12 13:36:43 UTC
10.1 is EOL. has r450634. This seems overcome by events.
Comment 6 Tijl Coosemans freebsd_committer freebsd_triage 2018-01-16 16:02:02 UTC
Please reopen if this is still a problem.