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 1REpQJ-0005uf-U3 for garchives@archives.gentoo.org; Fri, 14 Oct 2011 21:36:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 16BCE21C180; Fri, 14 Oct 2011 21:36:00 +0000 (UTC) Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com [209.85.215.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 3FE5021C17D for ; Fri, 14 Oct 2011 21:35:44 +0000 (UTC) Received: by eyx24 with SMTP id 24so1715635eyx.40 for ; Fri, 14 Oct 2011 14:35:44 -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 :content-type:content-transfer-encoding; bh=3NZHSnSPL3MY1RUJbODca99CZSZFferPdC7CZsNM6VU=; b=lnxsgI/GYyN6rKygdscW4D383cteFonCTAoJCfKViFAcTxPHSBJaP6NmYBvysv0WkG 3NW3fjKtvlmGiOkOpjbJ8qVLsRzs7SMXMhNLsJJYwxR/PGe65/qgCo0zYE7kbI05rWc2 zHArH/PMumvdqK9h9E5WuEPlps1sTvQg9l7qU= 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.14.85 with SMTP id f21mr6415882faa.37.1318628144408; Fri, 14 Oct 2011 14:35:44 -0700 (PDT) Received: by 10.223.108.73 with HTTP; Fri, 14 Oct 2011 14:35:44 -0700 (PDT) In-Reply-To: <201110141501.17986.vapier@gentoo.org> References: <201110131938.04592.vapier@gentoo.org> <201110141501.17986.vapier@gentoo.org> Date: Sat, 15 Oct 2011 01:35:44 +0400 Message-ID: Subject: Re: [gentoo-embedded] glibc+iconv From: Sergey Mironov To: gentoo-embedded@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 27bad8950da3503ddb4969430f342513 2011/10/14 Mike Frysinger : > On Friday 14 October 2011 06:11:40 Sergey Mironov wrote: >> 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 >> >> >> and 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 just 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' = config.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 >> > found in /usr/$CTARGET/usr/lib/gconv/ to do its actually work. =A0whic= h 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 whe= n i >> > implemented it, it was more of "let's save space on things i don't thi= nk >> > anyone will use". =A0but if people are using it, then installing these >> > things probably makes sense. >> >> 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 =A0/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? > > indeed, this is the current wonky behavior. =A0i guess the thing to do wo= uld be > two fold: > =A0 =A0 =A0 =A0- remove the disabling of tools/supplemental files so the = cross-compiler > glibc has all the same files as sys-libs/glibc > =A0 =A0 =A0 =A0- have crossdev automatically add a package.provided entry= to the > /usr/$CTARGET/etc/ tree for sys-libs/glibc Ok, thank you for explanations. I'll try to copy ebuild into my target's overlay and make neccesary modifications. >> 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. > > yes, the /usr/$CTARGET tree has no gcc files installed at all. =A0in nati= ve > installs, we've got /etc/env.d/ which adds the internal gcc paths via LDP= ATH > to ld.so.conf, and then ldso at runtime finds libstdc++.so and friends. = =A0but > gcc is not installed at all in /usr/$CTARGET. =A0in this case, you should= be > able to emerge gcc into /usr/$CTARGET since none of the cross-compiler gc= c > files should be in there ... > -mike > Yes, looks like I was wrong, libstdc++ is actually a library from gcc, not from glibc. Unfortunately, installing gcc on target may be expensive in my case, since we have some image size constraints. And we don't need compilers to be on target actually. Well, copying from /usr/lib/gcc/$CTARGET is not too bad since it shouldn't lead to conflicts. Maybe it also will be fine to delegate this task to crossdev one day. Sergey