public inbox for gentoo-embedded@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ed W <lists@wildgooses.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] Cross emerging to a given root.
Date: Fri, 04 Dec 2009 09:55:06 +0000	[thread overview]
Message-ID: <4B18DC7A.4090101@wildgooses.com> (raw)
In-Reply-To: <166af1cf0912031017w6ac9cfb8sa17f48c15d6f7cc9@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3773 bytes --]

  parent reply	other threads:[~2009-12-04 10:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-02 17:46 [gentoo-embedded] Cross emerging to a given root Shinkan
2009-12-02 20:04 ` Peter Stuge
2009-12-03 14:21   ` Shinkan
2009-12-03 16:52     ` Ed W
2009-12-03 18:17       ` Shinkan
2009-12-03 23:23         ` Peter Stuge
2009-12-04  9:55         ` Ed W [this message]
2009-12-04 10:25           ` Peter Stuge
2009-12-03 23:19     ` Peter Stuge
2009-12-02 20:09 ` Ryan Tandy
2009-12-03 16:50   ` Ed W

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B18DC7A.4090101@wildgooses.com \
    --to=lists@wildgooses.com \
    --cc=gentoo-embedded@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox