svn commit: r325668 - head/x11-toolkits/open-motif

[Boris Samorodov]

(moving the discussion to ports@)

30.08.2013 14:03, Guido Falsi пишет:

> On 08/30/13 11:52, Boris Samorodov wrote:
>> Author: bsam
>> Date: Fri Aug 30 09:52:20 2013
>> New Revision: 325668
>> URL: http://svnweb.freebsd.org/changeset/ports/325668
>>
>> Log:
>>    Fix build at 10.x after recent changes at /usr/bin/ld. Error log:
>>    ----
>>    ./../lib/Xm/.libs/libXm.so: undefined reference to `libiconv'
>>    ./../lib/Xm/.libs/libXm.so: undefined reference to `libiconv_close'
>>    ./../lib/Xm/.libs/libXm.so: undefined reference to `libiconv_open'
>>    -----
>>
>>    PR:		ports/181579
>>    Submitted by:	bsam (me)
>>    Approved by:	Mikhail Tsatsenko <m.tsatsenko at gmail.com> (maintainer)
>>
>> Modified:
>>    head/x11-toolkits/open-motif/Makefile
>>
>> Modified: head/x11-toolkits/open-motif/Makefile
>> ==============================================================================
>> --- head/x11-toolkits/open-motif/Makefile	Fri Aug 30 08:19:28 2013	(r325667)
>> +++ head/x11-toolkits/open-motif/Makefile	Fri Aug 30 09:52:20 2013	(r325668)
>> @@ -30,6 +30,7 @@ GNU_CONFIGURE=	yes
>>   USE_LDCONFIG=	yes
>>   MAKE_ENV=	LANG=C
>>   CPPFLAGS+=	-DCSRG_BASED -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -I${PREFIX}/include
>> +LDFLAGS+=	-L${PREFIX}/lib -liconv
>>   USE_CSTD=	gnu89
>>
>>   DEMOS_SRC=	${WRKSRC}/demos/programs
> 
> I'm having a lot of failures too related to libiconv symbols. These seem 
> related by enabling iconv in libc on latest current.
> 
> I'm not sure that forcing them to link against gnu libiconv is a good 
> long term solution.

Agreed. But this commit is not a log term solution. It's just a fix
which:
. preservs current status-quo (the port always depended upon libiconv);
. allow other ports which require this one to be build.

Thus it's just a bandaid.

> I think that making them work with just the libc 
> iconv implementation is a better solution, even if a little harder. It
> would allow us to not depend anymore on the libiconv port too.

I agree with a long term solution but we _need_ ports to work now.
So some of us patch the current tree, while others work on
infrastructure changes.

> I'm experimenting with making Uses/iconv.mk a noop for current where 
> libc includes iconv functions and making other ports compile using 
> system provided iconv. It looks doable, most ports need just trivial fixes.
>
> I was planning to ask an exp-run for this as soon as I am happy with my 
> findings.

If your changes may hit the portstree in a couple of days then it's OK
to wait. But if it takes longer, then broken ports should be patched
(like at this commit). And then please do whatever you think is needed.
BTW, one of those victims has almost 500(!) dependent ports:
http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-30_22h26m46s/

> If anyone is interested or has better insight regarding  this please 
> contact me.
> 
> (Also CCing peter, who made the commit to head, and could be interested)


-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve