On 08/31/13 15:38, Dimitry Andric wrote:
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.
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 <madpi...@freebsd.org>
_______________________________________________
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"
