On Aug 31, 2013, at 13:08, Boris Samorodov <b...@passap.ru> 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' ... >> 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.
Yes, the basic problem is that programs do "#include <iconv.h>", which pulls in /usr/local/include/iconv.h (the GNU version) instead of /usr/include/iconv.h (the base version). The GNU version redefines all the iconv-related functions to point to the GNU implementations. However, most configure scripts fail to detect that the linker flags should then be modified to add -L/usr/local/lib -liconv. I don't know of a good way to force ports to ignore the GNU version of iconv.h, and use the base iconv.h instead. Maybe we should rename the GNU version to gnuiconv.h, and use some sort of wrapper header to make sure ports only get the GNU version when they really want or need it. -Dimitry _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
