wget seems to have an unmarked direct dependency on libiconv

[ned-deily (Ned Deily)]

# port install wget -universal -ssl  # (same libiconv result with +universal)
# port deps wget -universal -ssl
Full Name: wget @1.16_0
Extract Dependencies: xz
Build Dependencies:   texinfo, perl5
Library Dependencies: libidn, gettext, pcre
# otool -L /macports/bin/wget
/macports/bin/wget:
	/macports/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
	/macports/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
	/macports/lib/libnettle.4.dylib (compatibility version 4.0.0, current version 4.7.0)
	/macports/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/macports/lib/libidn.11.dylib (compatibility version 18.0.0, current version 18.12.0)
	/macports/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.4.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.16.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

Might this be why some people have reported problems with wget and libiconv incompatibilities? See ​http://stackoverflow.com/questions/13301786/how-to-fix-libiconv-error-on-mac/

[ryandesign (Ryan Carsten Schmidt)]

The fact that the dependency on libiconv is undeclared is not really a problem, since dependency gettext has a libiconv dependency, and that's in fact the only reason why wget is linking with libiconv. The reason wget links with libiconv directly, rather than letting it happen indirectly through gettext, is an old Tiger bug (#18276) which I don't think even applies anymore, now that we've switched Tiger to using MacPorts-provide Apple gcc 4.2. I can look into that and remove it.

As to the stack overflow question you posted, I would refer the reporter to ProblemHotlist#libiconv-version

[ned-deily (Ned Deily)]

OK, thanks, I'd forgotten about the hotlist issue and also wasn't sure how this would work for binary packages.

[ryandesign (Ryan Carsten Schmidt)]

r129171

[ryandesign (Ryan Carsten Schmidt)]

Replying to nad@…:

wasn't sure how this would work for binary packages.

Regardless whether you installed from binary or built from source, an outside force can replace your MacPorts-installed files with broken ones. If that happened, reinstall the correct files using MacPorts. There is no need to force a build from source; that would only be necessary if our binary packages were known to be broken, and that is not known to be the case for libiconv; in fact it would greatly surprise me if that were the case since we have had no other reports about it and libiconv hasn't been updated (hasn't needed an update) in over 3 years.