From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OK8F8-0000ms-6T for garchives@archives.gentoo.org; Thu, 03 Jun 2010 11:05:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0722E0DA6 for ; Thu, 3 Jun 2010 11:05:45 +0000 (UTC) Received: from mail1.nippynetworks.com (mail1.nippynetworks.com [212.227.250.41]) by pigeon.gentoo.org (Postfix) with ESMTP id 54969E092D for ; Thu, 3 Jun 2010 10:42:27 +0000 (UTC) Received: from localhost (mail1.nippynetworks.com [127.0.0.1]) by mail1.nippynetworks.com (Postfix) with ESMTP id 44140675602; Thu, 3 Jun 2010 11:42:25 +0100 (BST) X-Virus-Scanned: amavisd-new at nippynetworks.com Received: from mail1.nippynetworks.com ([127.0.0.1]) by localhost (mail1.nippynetworks.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ELJi-dpUnkt; Thu, 3 Jun 2010 11:42:25 +0100 (BST) Received: from Ed-Wildgooses-MacBook-Pro.local (office.nippynetworks.com [94.194.201.187]) (Authenticated sender: edward@wildgooses.com) by mail1.nippynetworks.com (Postfix) with ESMTPSA id E20F767405F; Thu, 3 Jun 2010 11:42:24 +0100 (BST) Message-ID: <4C078710.8060808@wildgooses.com> Date: Thu, 03 Jun 2010 11:42:24 +0100 From: Ed W User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 To: gentoo-embedded@lists.gentoo.org CC: flameeyes@gentoo.org Subject: [gentoo-embedded] ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e0fa1b44-a729-4c91-8b5b-0bf3fd76a759 X-Archives-Hash: 17ff4d77f257e457c74171aec70ac944 Hi, replying here rather than on the bug tracker, but please set me=20 straight if it's better discussed elsewhere? (In reply to comment #11 - Diego) > The problem is not build, the problem is that if libiconv is removed=20 _after_ > gcc is merged=85 it breaks. > I have seen you and others note this several times (and the reason why=20 seems clear), however, what I don't get is why this is any different to=20 the normal situation with glibc? Q: Why would libiconv ever be uninstalled/removed? Q: After installing libiconv and rebuilding gettext/gcc, the upgrade=20 process to a new libiconv presumably then becomes, 1) upgrade libiconv,=20 2) rebuild gettext/gcc, 3) delete old libiconv libraries? Sounds bearable= ? Is the problem that under glibc there is no dependency created at all=20 with regards to iconv, but if libiconv is floating around then there is=20 a dep created? And subsequently it's "hard" to avoid recompiles of gcc=20 picking up libiconv, hence ever removing that dependency? Is this basically the same issue with gettext on uclibc? I guess the real question here is what's the best way to build glib=20 under uclibc? Recommendations please? Thanks Ed W