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

[Dimitry Andric]

On Aug 31, 2013, at 13:08, Boris Samorodov <bsam at 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