devel/sope: make (stage-qa) now fails with DEVELOPER=yes complaining about iconv dependency

Don Lewis truckman at
Fri Jul 15 16:10:25 UTC 2016

On 15 Jul, Euan Thoms wrote:
> On Friday, July 15, 2016 15:26 SGT, Kubilay Kocak <koobs at>
> wrote:
>> On 15/07/2016 5:17 PM, Martin Waschbüsch wrote:
>> > 
>> >> Am 14.07.2016 um 23:29 schrieb Euan Thoms <euan at>:
>> >> 
>> >> 
>> >> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld
>> >> <w.schwarzenfeld at> wrote:
>> >> 
>> >>> I think this statements should be only warnings. Cause not all
>> >>> of these statements are right and each maintianer should decide
>> >>> which "USES" or "LIB_DEPENDS" are necessairely and which not.
>> >> 
>> >> Well, I don't know enough to comment about whether it should be
>> >> classed as a warning or an error. But there's definetely a bug in
>> >> the ports Mk system, since adding USES+=iconv does not remove the
>> >> error. I don't think I even need iconv as a dependency, it should
>> >> be included lower down in the dependency tree.
>> > 
>> > I am not sure about this. At the very least, sope-core does use
>> > iconv in its NGExtensions (e.g. NSString+Encoding.m). Can we really
>> > assume some lower dependency package already pulls iconv in?
>> If something in a port links to libiconv (or anything else), then
>> the dependency should be registered in that port
> OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still
> think there may be a bug. The make error tells me to use USES+=iconv
> and it doesn't work, I still get the same error about libiconv not
> being specified as a dependancy.

It looks like USES=iconv doesn't add the dependency on newer FreeBSD
versions that have basic iconv support in the base system.  If you set
USES=iconv:wchar_t or USES=iconv:translit, then it will unconditionally
add the dependency.

If you don't use the WCHAR_T or //TRANSLIT extensions, it may not be
necessary to link with -liconv, but it is possible that the port does
this automatically if it finds that libiconv is installed by another

More information about the freebsd-ports mailing list