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

[Dimitry Andric]

On Aug 31, 2013, at 16:28, Guido Falsi <madpilot at freebsd.org> wrote:
> On 08/31/13 15:38, Dimitry Andric wrote:
...
>> 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.
...
> I have spent a few hours experimenting and produced this PR:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181693
> 
> The fixes themselves are trivial and for the subset of ports I have tested it seems to work fine. I have asked for an exp-run since I don't have the horsepower to properly test all the ports tree in an acceptable time frame.
> 
> Most of the problematic ports seem not to work because of our patches in the ports tree forcing them to look in /usr/local/ for iiconv, while the software itself would prefer to use the system iconv implementation if left to it's own devices.
> 
> My patch there is a little messy perhaps, since I had to make all the Makefile changes conditional to the OS version. I'm quite sure cleaner patches can be worked out, but I wanted to set some starting point.
> 
> I hope my work on this to be useful, and will try to improve it. I'm quite open to suggestions and improvements. Thats why I decided to send this email.


I don't think your approach will work correctly.  For every port, you
basically add:

+.if !exists(/usr/include/iconv.h) && ${OSVERSION} < 1000043
 LIB_DEPENDS+=       libiconv.so.3:${PORTSDIR}/converters/libiconv
+.endif

However, if someone has the libiconv port installed through some other
means, almost any iconv-using port will still find the GNU iconv.h
header before the base iconv.h header, so the problem of linking against
the base iconv implementation is not solved.

I suspect that the only robust way of solving this is with a wrapper
header in /usr/local/include.  Or by entirely banning GNU iconv. ;-)

-Dimitry