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