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

Guido Falsi madpilot at FreeBSD.org
Sat Aug 31 14:28:24 UTC 2013


On 08/31/13 15:38, Dimitry Andric wrote:
> 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.

I understand this. In fact, I'm sorry if my comment looked aggressive.

I simply replied to your commit because it was a good starting point for 
this subject

>
> 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
>

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.

-- 
Guido Falsi <madpilot at FreeBSD.org>


More information about the freebsd-ports mailing list