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 <[email protected]> (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
pgpw3d564x7aj.pgp
Description: PGP signature
