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 1NGV8o-0004je-9z for garchives@archives.gentoo.org; Fri, 04 Dec 2009 10:11:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 84959E0741 for ; Fri, 4 Dec 2009 10:11:57 +0000 (UTC) Received: from mail1.nippynetworks.com (mail1.nippynetworks.com [212.227.250.41]) by pigeon.gentoo.org (Postfix) with ESMTP id DD14FE06F7 for ; Fri, 4 Dec 2009 09:55:08 +0000 (UTC) Received: from localhost (mail1.nippynetworks.com [127.0.2.1]) by mail1.nippynetworks.com (Postfix) with ESMTP id 44B5D6746ED for ; Fri, 4 Dec 2009 09:55:08 +0000 (GMT) X-Virus-Scanned: amavisd-new at nippynetworks.com Received: from mail1.nippynetworks.com ([127.0.2.1]) by localhost (mail1.nippynetworks.com [127.0.2.1]) (amavisd-new, port 10024) with LMTP id ptmh6yPjiRVT for ; Fri, 4 Dec 2009 09:55:08 +0000 (GMT) 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 DEB596746D8 for ; Fri, 4 Dec 2009 09:55:07 +0000 (GMT) Message-ID: <4B18DC7A.4090101@wildgooses.com> Date: Fri, 04 Dec 2009 09:55:06 +0000 From: Ed W User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) 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 Subject: Re: [gentoo-embedded] Cross emerging to a given root. References: <166af1cf0912020946g110c8d53ib1d844a5b370d7b7@mail.gmail.com> <20091202200422.4470.qmail@stuge.se> <166af1cf0912030621g56dafb57wbd16eaf95485b37@mail.gmail.com> <4B17ECB7.4000800@wildgooses.com> <166af1cf0912031017w6ac9cfb8sa17f48c15d6f7cc9@mail.gmail.com> In-Reply-To: <166af1cf0912031017w6ac9cfb8sa17f48c15d6f7cc9@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060200080108050205000205" X-Archives-Salt: 6cca2d05-b325-4303-869e-c4f49fcb863b X-Archives-Hash: a66292bdec9f63dfc28b6e768685e635 This is a multi-part message in MIME format. --------------060200080108050205000205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi > lzma failed to run because of something it didn't like in libstdc++ > from /usr/lib/gcc/my-other-gcc-version/ or something like that. My point exactly, your problem report was completely about the wrong thing - you were reporting a problem on the host when you meant to report a problem on the target.... Lots of stuff just assumes that GCC is installed and fails to specify it in the RDEPENDS. Just copy across the relevant library manually if you don't want the whole of the package installed > I'm not exactly on the TinyGentoo case because I would prefer host to > serves as a build env instead of untaring another stage3. ?? The extra stage is just a clean way to have a known build environment? Nothing wrong with using your normal host OS, but using a chroot means you can version/backup/lockdown the build environment. In case you misunderstand the idea is not to just pull down a stage3 or whatever each time? You can just make a copy of your normal OS if you wish instead? The point was just to have a minimal chroot with largely only the stuff you need to build your targets > As I have many various targets to build and maintain, it would be hard > to also maintain their respective build chroots. Why? Can't be any harder to maintain one (optionally more) locked down, backed up chroots than your whole main OS that could change at any time... If you upgrade glibc on your host then the targets could all become bolloxed Remember you have all kinds of tricks to use to simplify maintenance of your one or more chroots, eg binary packages, hardlinks, scripts, etc Fundamentally this is the game catalyst seems to be playing, ie build one build environment to build the final build > For now I play with gcc-config on host every time I work with a target > which needs a different gcc, but that's much pain (what if I forget to > gcc-config back to my actual host gcc version ??! I'll lscrew my host > I guess.) Chroots and some wrapper scripts... > I would really like if there was an option on make.conf to specify > default compiler. As each of my targets have its own make.conf and > profile link, it would be very comfortable if I could tell emerge to > use the compiler specified in make.conf, so that each time I'd > cross-emerge, the good compiler for my target would be selected. Read the docs for portage. The make.conf/portage dirs used are all configurable using environment variables - hence you can have multiple profiles for different targets. It nearly works as advertised... Couple of quirks Note it won't switch compilers, but this seems very easily scripted (./setup_build_environment myquirkybuilds_2) Ed --------------060200080108050205000205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi

lzma failed to run because of something it didn't like in libstdc++ from /usr/lib/gcc/my-other-gcc-version/ or something like that.

My point exactly, your problem report was completely about the wrong thing - you were reporting a problem on the host when you meant to report a problem on the target....

Lots of stuff just assumes that GCC is installed and fails to specify it in the RDEPENDS.=C2=A0 Just copy across the relevant library manually = if you don't want the whole of the package installed

I'm not exactly on the TinyGentoo case because I would prefer host to serves as a build env instead of untaring another stage3.

?? The extra stage is just a clean way to have a known build environment?=C2=A0 Nothing wrong with using your normal host OS, but usin= g a chroot means you can version/backup/lockdown the build environment.=C2=A0=

In case you misunderstand the idea is not to just pull down a stage3 or whatever each time?=C2=A0 You can just make a copy of your normal OS if y= ou wish instead?=C2=A0 The point was just to have a minimal chroot with larg= ely only the stuff you need to build your targets

As I have many various targets to build and maintain, it would be hard to also maintain their respective build chroots.

Why?=C2=A0 Can't be any harder to maintain one (optionally more) locked down, backed up chroots than your whole main OS that could change at any time...=C2=A0 If you upgrade glibc on your host then the targets coul= d all become bolloxed

Remember you have all kinds of tricks to use to simplify maintenance of your one or more chroots, eg binary packages, hardlinks, scripts, etc
=
Fundamentally this is the game catalyst seems to be playing, ie build one build environment to build the final build

For now I play with gcc-config on host every time I work with a target which needs a different gcc, but that's much pain (what if I forget to gcc-config back to my actual host gcc version ??! I'll lscrew my host I guess.)

Chroots and some wrapper scripts...

I would really like if there was an option on make.conf to= specify default compiler. As each of my targets have its own make.conf and profile link, it would be very comfortable if I could tell emerge to use the compiler specified in make.conf, so that each time I'd cross-emerge, the good compiler for my target would be selected.

Read the docs for portage.=C2=A0 The make.conf/portage dirs used are all configurable using environment variables - hence you can have multiple profiles for different targets.=C2=A0 It nearly works as advertised... Couple of quirks

Note it won't switch compilers, but this seems very easily scripted (./setup_build_environment myquirkybuilds_2)

Ed
--------------060200080108050205000205--