Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 600452 - net-misc/wget-1.18 fails to link on Cygwin due to missing libiconv on link line
Summary: net-misc/wget-1.18 fails to link on Cygwin due to missing libiconv on link line
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Other
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: prefix-gx86
  Show dependency tree
 
Reported: 2016-11-22 08:33 UTC by Michael Haubenwallner (RETIRED)
Modified: 2017-10-24 17:21 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
wget-1.18 ebuild diff (wget-1.18-cygwin.diff,560 bytes, patch)
2016-11-22 08:33 UTC, Michael Haubenwallner (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Haubenwallner (RETIRED) gentoo-dev 2016-11-22 08:33:35 UTC
Created attachment 454012 [details, diff]
wget-1.18 ebuild diff

Fix for #585924 and #587620 also applies to Cygwin, thanks!
Comment 1 Felix Janda 2016-11-22 11:52:05 UTC
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.
Comment 2 Felix Janda 2016-11-22 12:29:55 UTC
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.
Comment 3 Michael Haubenwallner (RETIRED) gentoo-dev 2016-11-22 16:24:49 UTC
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.
Comment 4 Felix Janda 2016-11-22 18:54:47 UTC
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...
Comment 5 Thomas Deutschmann (RETIRED) gentoo-dev 2017-10-24 17:21:14 UTC
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.