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

[Baptiste Daroussin]

On Sat, Aug 31, 2013 at 03:08:36PM +0400, Boris Samorodov wrote:
> (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/
> 

This last build with with libc++ activated by default, it has fallout from both
iconv in libc and and libc++.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130831/1034a219/attachment.sig>