Created attachment 454012 [details, diff] wget-1.18 ebuild diff Fix for #585924 and #587620 also applies to Cygwin, thanks!
Sorry for derailing this bug, but wouldn't it be more robust to patch configure.ac. It contains # For some reason, this seems to be set even when we don't check. # Explicitly unset. LIBICONV= since 2009. That is I think what has caused the weirdness in: http://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00025.html If patching configure.ac works, this should really be reported upstream.
Also, why don't we unconditionally patch configure (or configure.ac)? When no libiconv is present, LIBICONV will be empty anyway. Also I think I have some guess why the code cited in comment 1 was added to configure.ac in 2009. Although the macro "AM_ICONV" is inside an AS_IF block testing whether IDN/IRI support is requested the corresponding configure tests for iconv are done unconditionally (compare to the generated configure script). Subsequently, LIBICONV gets set unconditionally. In 2009, it was only necessary to link against libiconv when IDN/IRI support was enabled. So to avoid unecessary linking against libiconv they set LIBICONV to be empty. More recently, support for non-ASCII URLs was added to src/url.c. This is conditional on HAVE_ICONV. The current bug happens when iconv is in a separate libiconv, and IDN/IRI is not requested: As always, configure will detect iconv, set HAVE_ICONV to 1, and set LIBICONV to -liconv. Later LIBICONV will be unset again because IDN/IRI support is disabled. The code using iconv in src/url.c will be compiled because HAVE_ICONV is still 1. Since -liconv was removed from LIBICONV, we will fail at link time.
Felix, thanks for the insight - might serve as step forward to some "correct" upstream fix! For the ebuild: patching configure.ac would add autotools dependency, breaking some bootstrap procedures - thus we patch configure instead. For upstream: According to http://savannah.gnu.org/bugs/?48193 they've committed something to be shipped with wget-1.18.1. Although that change doesn't fit your description, let's see how it unbreaks things for us.
Thanks for explaining which you avoid patching configure.ac. I don't see a revision of upstream git that the patch in the upstream bug you mention would apply to, but the commit http://git.savannah.gnu.org/cgit/wget.git/commit/src/Makefile.am?id=d4f97dc9afd149afe1f7b16a84eebb4bab1f044a seems like a fix. The commit 59b920874daa mentioned in the upstream bug is the commit adding support for non-ASCII URL to src/url.c. So this matches up my theory. I am looking into sending a patch cleaning up this mess...
git tag --contains d4f97dc9afd149afe1f7b16a84eebb4bab1f044a v1.19 v1.19.1 net-misc/wget-1.19.1-r1 is the only version available within Gentoo so I am considering this as fixed. Please re-open if you still have this problem.
