Date: Tue, 03 Feb 2015 01:26:31 +0100 From: John Marino <freebsd.contact@marino.st> To: koobs@FreeBSD.org, John Marino <marino@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r378316 - head/devel/libhtp Message-ID: <54D015B7.2080408@marino.st> In-Reply-To: <54D01223.7020703@FreeBSD.org> References: <201502021841.t12IfvP1021156@svn.freebsd.org> <54D01223.7020703@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/3/2015 01:11, Kubilay Kocak wrote: > On 3/02/2015 5:41 AM, John Marino wrote: >> Author: marino >> Date: Mon Feb 2 18:41:56 2015 >> New Revision: 378316 >> URL: https://svnweb.freebsd.org/changeset/ports/378316 >> QAT: https://qat.redports.org/buildarchive/r378316/ >> >> Log: >> devel/libhtp: tweak recent iconv:translit change to fix on some compilers >> >> When USES=iconv is changed to USES=iconv:translit, it can add libiconv >> dependency from ports along with the addition of -liconv to LDFLAGS. >> Most compilers (with FreeBSD's base compilers being notable exceptions) >> will not look in /usr/local/lib by default, so this adds a -L argument >> to LDFLAGS to help the linker find libiconv.so and unbreak the port on >> affected platforms. >> >> Modified: >> head/devel/libhtp/Makefile >> >> Modified: head/devel/libhtp/Makefile >> ============================================================================== >> --- head/devel/libhtp/Makefile Mon Feb 2 18:39:38 2015 (r378315) >> +++ head/devel/libhtp/Makefile Mon Feb 2 18:41:56 2015 (r378316) >> @@ -20,6 +20,7 @@ USE_LDCONFIG= yes >> GNU_CONFIGURE= yes >> CONFIGURE_ARGS= ${ICONV_CONFIGURE_ARG} >> MAKE_ARGS= LIBS="-lz ${ICONV_LIB}" >> +LDFLAGS+= -L${LOCALBASE}/lib >> >> PATHFIX_MAKEFILEIN= Makefile.am >> >> > > Apart from the lack of an Approved by: line for this commit, even in the > case of blanket, isn't LIBS= better here? It was a blanket - when ports that were building on dfly suddenly break and the fix is simple and not invasive (e.g. missing LDFLAG) then I've been given a blanket to just fix it. I don't know if "LIBS" is standardized but it's a flag that's missing, not a library. > > Further, if it is indeed the case that iconv:translit adds -liconv to > LDFLAGS, wouldn't adding -L${LOCALBASE}/lib to LDFLAGS be better solved > in Uses/iconv.mk when that case is true? I would think so. Most of the time this doesn't pop up because another dependency brings in -L/usr/local/lib so it works by accident very often. At the very least it should have an ${LDFLAGS_ICONV} option that could be added to LDFLAGS. It would be a more correct solution. > Give me a holler on IRC or email in future if you notice anything up > with ports I maintain. I'm almost always happy to oblige. I not on IRC ATM and I didn't see the downside of unbreaking the port with a single flag. I would have opened a bugzilla ticket if the fix was not obvious or invasive; I do that all the time. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D015B7.2080408>