From owner-freebsd-stable@FreeBSD.ORG Mon Nov 18 12:47:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F5E5F15 for ; Mon, 18 Nov 2013 12:47:02 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1694D27CB for ; Mon, 18 Nov 2013 12:47:01 +0000 (UTC) Received: from fortune.joker.local (180-198-98-49.nagoya1.commufa.jp [180.198.98.49]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.2/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id rAICl0fs073735 for ; Mon, 18 Nov 2013 21:47:00 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 18 Nov 2013 21:47:00 +0900 From: Tomoaki AOKI To: freebsd-stable@freebsd.org Subject: Re: Please revert r258230 in stable/10 Message-Id: <20131118214700.97ad4cd44af9989ac9ff88d1@dec.sakura.ne.jp> In-Reply-To: <20131118213553.2da2f1b08a30d6aecc04a46d@dec.sakura.ne.jp> References: <20131117114223.9af2adf49a93b5dd7f77f472@dec.sakura.ne.jp> <5288BFB6.3010709@passap.ru> <20131118213553.2da2f1b08a30d6aecc04a46d@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 12:47:02 -0000 Sorry. I forgot to mention. All my test proceeded in head is intentionally done at revision r258284, as I noticed base iconv framework is modified (looks mainly in namespace changes) in r258283 and __FreeBSD_version is bumped at r258284 correspondingly. Also, stable/10 is at r258230 and stable/9 host is at r258161. All is amd64, head and stable/10 in VirtualBox guest in stable/9 host. On Mon, 18 Nov 2013 21:35:53 +0900 Tomoaki AOKI wrote: > On Sun, 17 Nov 2013 17:08:06 +0400 > Boris Samorodov 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com