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 --]
next prev 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