As some port requires libiconv.so.3 and currently converters/libiconv refuses to install if base iconv exists, WITH_LIBICONV_COMPAT option and related codes are still mandatory (preferrebly, default for 10.x). Please revert r258230 until any workaround is provided. If a PR is needed to revert, I'll do it. At least, japanese/mozc-tools (I and maybe many Japanese desktop users strongly need japanese/mozc-* ports, and it unconditionally requires libiconv.so.3) didn't build in head after r257583, which is MFC'ed this time. I think more and more ports would be affected. At that time, it was only in head, and no MFC date is targetted, so I didn't mention as I thought we users would have 2+ years to wait for base and ports to be finished by developers, or same time for discussion of proceeding or restoring WITH_LIBICONV_COMPAT knob. IMHO, as converters/libiconv refuses to be installed if /usr/include/iconv.h exists, namespace spoofing to ports libiconv stated in original commit message can't occur in fresh installation, isn't it? This case, using same namespace and individual names would be mandatory to fake port libiconv consumers (if not, meaning incompatible). No harm can exist this case. Am I missing something? As stable/10 and upcoming 10-RELEASE are the first version that base iconv libraries are default, and converters/libiconv does not want coexisting (at least, using current and plain ports tree to build) with base iconv, special care is needed for now. Possible workarounds I can imagine currently are: *Of course, reverting r258230 for 10.x lifetime for transition. *Merge now-removed base Citrus libiconv codes into converters/libiconv and conditionally build real gnu libiconv or Citrus based libiconv by checking existence of /usr/include/iconv.h. But I can't imagine actual how-to. I guess the latter can cause license management issue, but creating a new port for this shouldn't be an option to avoid dependency hell. Or can it be handled using some USES code? I'm not enough familiar to ports framework. -- Tomoaki AOKI junchoon at dec.sakura.ne.jp
On Sun, Nov 17, 2013 at 11:42:23AM +0900, Tomoaki AOKI wrote:> As some port requires libiconv.so.3 and currently converters/libiconv > refuses to install if base iconv exists, WITH_LIBICONV_COMPAT option > and related codes are still mandatory (preferrebly, default for 10.x). > Please revert r258230 until any workaround is provided. > If a PR is needed to revert, I'll do it. >No, WITH_LIBICONV_COMPAT makes things worse. It was removed because it does much more harm than it does good. The remaining issues you mentioned are known, and we are working on solutions. Glen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131116/049a2b21/attachment.sig>
17.11.2013 06:42, Tomoaki AOKI ?????:> As some port requires libiconv.so.3Are you speaking in general or do you have other (than japanese/mozc-tools) examples?> At least, japanese/mozc-tools (I and maybe many Japanese desktop users > strongly need japanese/mozc-* ports, and it unconditionally requires > libiconv.so.3) didn't build in head after r257583I just tried to build japanese/mozc-tools. Do you speak about this?: ----- LINK(target) out_linux/Release/mozc_tool /usr/bin/ld: cannot find -liconv c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [out_linux/Release/mozc_tool] Error 1 ----- If yes, I'd say that it's not a hard dependency upon libiconv but just a configure error. Please, try the attached patch (build tested only) and report back. We will be interested at run time behaviour (is it OK or not). Seems that the patch has an effect only on mozc-tools, but to be on a safe side I'd rebuild all mozc-* ports. Thank you for the report. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve -------------- next part -------------- A non-text attachment was scrubbed... Name: mozc-tool.iconv-fix.diff Type: text/x-diff Size: 603 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131117/e5a4ed3e/attachment.diff>