Date: Sat, 31 Aug 2013 17:21:09 +0200 From: Guido Falsi <madpilot@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, Boris Samorodov <bsam@passap.ru>, Peter Wemm <peter@wemm.org>, FreeBSD ports list <freebsd-ports@FreeBSD.org> Subject: Re: svn commit: r325668 - head/x11-toolkits/open-motif Message-ID: <522209E5.2030607@FreeBSD.org> In-Reply-To: <2EBE9400-E1EF-4F3D-9C63-8454DA05ED90@FreeBSD.org> References: <201308300952.r7U9qKsF026518@svn.freebsd.org> <52206DF8.1000401@FreeBSD.org> <5221CEB4.7090109@passap.ru> <B9A33C6E-B731-4862-B50E-74F52924FB7E@FreeBSD.org> <5221FD7C.1040501@FreeBSD.org> <2EBE9400-E1EF-4F3D-9C63-8454DA05ED90@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/31/13 16:42, Dimitry Andric wrote: > On Aug 31, 2013, at 16:28, Guido Falsi <madpilot@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. ;-) 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 <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?522209E5.2030607>