Date: Mon, 18 Nov 2013 21:35:53 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: freebsd-stable@freebsd.org Subject: Re: Please revert r258230 in stable/10 Message-ID: <20131118213553.2da2f1b08a30d6aecc04a46d@dec.sakura.ne.jp> In-Reply-To: <5288BFB6.3010709@passap.ru> References: <20131117114223.9af2adf49a93b5dd7f77f472@dec.sakura.ne.jp> <5288BFB6.3010709@passap.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Nov 2013 17:08:06 +0400
Boris Samorodov <bsam@passap.ru> wrote:
> 17.11.2013 06:42, Tomoaki AOKI пишет:
>
> > As some port requires libiconv.so.3
>
> Are you speaking in general or do you have other (than
> japanese/mozc-tools) examples?
Sorry for delay.
I'm speaking in general, and japanese/mozc-tool is an example I found
within my limited test. Many ports have iconv option, many have
non-optionally depends on libiconv, and possibly having problem.
I guess some of those are only configure issue as you mentioned, some
of those are handled properly via USES=iconv, but some others possibly
have severe dependency issue, I suspect.
Note: I additionally found security/clamav (with OPTIONS iconv enabled),
devel/sdl12 (non-optional USES), and print/ghostscript9 (with
OPTIONS but default) misses libiconv.so.3 by pkg_libchk. All these
was rebuilt fine and confirmed at least clamav runs fine, in
head and stable/10. Because devel/sdl12 and print/ghostscript9 was
installed as dependency of something, I haven't test them yet.
> > 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
>
> I 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.
Tried, for safety, rebuilding mozc-* ports and ibus-mozc port.
Your patch looks working fine for me in both head and stable/10, and
additionally, stable/9 host environment (with converters/libiconv, no
base iconv libraries built). All is OK for me. Thanks.
While testing this, I found libiconv.so.3 is left unremoved
in /usr/lib32 after make delete-old and make delete-old libs with
libiconv.so (symlink to libiconv.so.3), libiconv.a and libiconv_p.a (I'm
trying amd64).
Of course it shouldn't affect for natively compiled version, but for
safer test, renaming them and rebuild all mozc-* ports. Still looks OK.
> Thank you for the report.
> --
> WBR, Boris Samorodov (bsam)
> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
--
Tomoaki AOKI junchoon@dec.sakura.ne.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131118213553.2da2f1b08a30d6aecc04a46d>