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 1REekJ-00077k-JF for garchives@archives.gentoo.org; Fri, 14 Oct 2011 10:12:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4EA5C21C04B; Fri, 14 Oct 2011 10:11:54 +0000 (UTC) Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181]) by pigeon.gentoo.org (Postfix) with ESMTP id DC3A821C047 for ; Fri, 14 Oct 2011 10:11:41 +0000 (UTC) Received: by gye5 with SMTP id 5so1239201gye.40 for ; Fri, 14 Oct 2011 03:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ONLpkN6HA7Cm0wcL9aLS70PAGQTZMKyoge6yX8HPzwA=; b=G+Fo7c0/AAXb2/vwjKfAOgFb9rmeZbLj1x0QgRB8CPEu3lpqNHqyFTEaXpulbOWW0E WB7zttN+8cTgIwMdaHt5qsaTEogn8VWSay5gi03s2MMLgTqEorltCcPm6bKpDyV1PeqV 2vmS2oYVkkQORpludX/cJiWwrktLWTC5F+AFU= 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 Received: by 10.223.75.25 with SMTP id w25mr3275389faj.15.1318587101015; Fri, 14 Oct 2011 03:11:41 -0700 (PDT) Received: by 10.223.108.73 with HTTP; Fri, 14 Oct 2011 03:11:40 -0700 (PDT) In-Reply-To: <201110131938.04592.vapier@gentoo.org> References: <201110131909.43420.vapier@gentoo.org> <201110131938.04592.vapier@gentoo.org> Date: Fri, 14 Oct 2011 14:11:40 +0400 Message-ID: Subject: Re: [gentoo-embedded] glibc+iconv From: Sergey Mironov To: Mike Frysinger Cc: gentoo-embedded@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 3946151ff5406246eef63c56400025be 2011/10/14 Mike Frysinger : > On Thursday 13 October 2011 19:30:14 Sergey Mironov wrote: >> 2011/10/14 Mike Frysinger: >> > On Thursday 13 October 2011 15:15:40 Sergey Mironov wrote: >> >> Hello. I have my arm-unknown-linux-gnueabi system which uses glibc an= d >> >> busybox. Recently I realised that iconv program doesn't exist in the >> >> tree. I've compared host's and target's glibc file lists and found >> >> that arm's version doesn't install anything to >> >> /usr/arm-unknown-linux-gnueabi/usr/bin. What can be the cause of this= ? >> >> Small C program shows that iconv_open function returns error code jus= t >> >> like if there is no iconv at all. How shoud I make arm's iconv work? >> > >> > see glibc's files/eblits/src_compile.eblit: >> > =A0 =A0 =A0 =A0is_crosscompile && sed -i '1ibuild-programs =3D no' con= fig.make >> > >> > i imagine disabling that line will get you `iconv` >> >> Thanks, I will try it! =A0Am I understand correctly that iconv itself >> (library, not program) is a part of glibc and it is not possible to >> exclude it during the build? So despite the lack of program I should >> still have fully functional library. > > your understanding is correct, however ........ > > iconv() is part of glibc but it relies on all of the gconv shared libs fo= und > in /usr/$CTARGET/usr/lib/gconv/ to do its actually work. =A0which we also > incidentally delete when building the cross-compiler glibc (see > src_install.eblit and look for "gconv"). > > you aren't the first person to find this behavior undesirable, and when i > implemented it, it was more of "let's save space on things i don't think > anyone will use". =A0but if people are using it, then installing these th= ings > probably makes sense. > -mike > Well, maybe I really want something strange. I guess, people often install another, non-cross-compiled version of glibc on top of initial one. I've tried to do so, but found that cross-emerge complains about conflicts - it simply doesn't treat initial glibc as a package installed on target. I saw 2 ways - either edit package.provided and don't install new glibc or disable conflicts detection and overwrite some target's /lib* and /usr/lib/* files. I've chosen first way since I am afraid of getting a mess of two glibc's compiled with different tools. But how do you (or other people) act in this situation? By the way, I also had to handcopy libstdc++.so from /usr/lib/gcc/$CTARGET to /usr/$CTARGET/lib to make C++ programs work. It is another thing which makes me thinking of installig full glibc on top of cross-one. Sergey