On 08/31/13 16:42, Dimitry Andric wrote:
On Aug 31, 2013, at 16:28, Guido Falsi <[email protected]> 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. ;-)
The basic idea was making Uses/iconv.mk a noop. That would prevent the
iconv port from being installed automatically as a dependency by any port.
The patch is just a functional one to test it in an exp-run[1]. With
that patch no port should pull it in. I still did not spend time adding
an UPDATING message or some warning to the iconv ports etc.
We will for sure need instructions for migration in UPDATING, telling
people to remove the gnu iconv port, which, unless the system is
compiled with WITH_LIBICONV_COMPAT, means reinstalling all ports
depending on libiconv. This is the most problematic part, the one I have
still to think a good solution for.
It should not be a problem for people moving from <= 9.x: we anyway
still require people to rebuild all ports when doing a major update.
It's a problem for people already using 10. Your idea about a
placeholder port installing an header file in /usr/local/include could
be quite a good idea. We could force a procedure like this:
portmaster -o converters/iconv-magic converters/iconv
portmaster -r converters/iconv-magic
pkg delete converters/iconv-magic
this could work provided we can create a "iconv-magic" port capable of
filling the role :) [2]
There is also a need for some king of guard in the GNU iconv port; any
combination of: rename it to gnuiconv, add a big warning, mark it
deprecated, etc. the last two could be easier to implement since no
change would be visible for older releases.
At this point I clearly see that we need to make a decision up front of
how much we want to support the gnu iconv library for 10.x and future
releases. Easier solution would be to bless the system iconv and clearly
state that the GNU iconv is just and unsupported alternative provided on
a best effort basis.
Making the ports tree work with both looks quite painful and difficult
to achieve.
These are my ideas, obviously. It's quite possible I'm missing some
important aspect.
[1] I also posted that PR thinking that putting some patch behind my
proposal would make the discussion easier and more serious. I anyway
spent time testing that patch, it may not be the best solution but does
perform the task at least partly. Some partial patch is anyway better
than no patch! ;)
[2] Not sure what such a port could contain. We need a iconv.h file,
perhaps pkgconf files. We definitely don't want a "libiconv.so" library
there, or we would anyway have binaries linked against that instead of
just using libc. Our purpose here is to not link against any libiconv.so
(no -liconv for linker commands)
--
Guido Falsi <[email protected]>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
