| 1 |
Hi |
| 2 |
|
| 3 |
> lzma failed to run because of something it didn't like in libstdc++ |
| 4 |
> from /usr/lib/gcc/my-other-gcc-version/ or something like that. |
| 5 |
|
| 6 |
My point exactly, your problem report was completely about the wrong |
| 7 |
thing - you were reporting a problem on the host when you meant to |
| 8 |
report a problem on the target.... |
| 9 |
|
| 10 |
Lots of stuff just assumes that GCC is installed and fails to specify it |
| 11 |
in the RDEPENDS. Just copy across the relevant library manually if you |
| 12 |
don't want the whole of the package installed |
| 13 |
|
| 14 |
> I'm not exactly on the TinyGentoo case because I would prefer host to |
| 15 |
> serves as a build env instead of untaring another stage3. |
| 16 |
|
| 17 |
?? The extra stage is just a clean way to have a known build |
| 18 |
environment? Nothing wrong with using your normal host OS, but using a |
| 19 |
chroot means you can version/backup/lockdown the build environment. |
| 20 |
|
| 21 |
In case you misunderstand the idea is not to just pull down a stage3 or |
| 22 |
whatever each time? You can just make a copy of your normal OS if you |
| 23 |
wish instead? The point was just to have a minimal chroot with largely |
| 24 |
only the stuff you need to build your targets |
| 25 |
|
| 26 |
> As I have many various targets to build and maintain, it would be hard |
| 27 |
> to also maintain their respective build chroots. |
| 28 |
|
| 29 |
Why? Can't be any harder to maintain one (optionally more) locked down, |
| 30 |
backed up chroots than your whole main OS that could change at any |
| 31 |
time... If you upgrade glibc on your host then the targets could all |
| 32 |
become bolloxed |
| 33 |
|
| 34 |
Remember you have all kinds of tricks to use to simplify maintenance of |
| 35 |
your one or more chroots, eg binary packages, hardlinks, scripts, etc |
| 36 |
|
| 37 |
Fundamentally this is the game catalyst seems to be playing, ie build |
| 38 |
one build environment to build the final build |
| 39 |
|
| 40 |
> For now I play with gcc-config on host every time I work with a target |
| 41 |
> which needs a different gcc, but that's much pain (what if I forget to |
| 42 |
> gcc-config back to my actual host gcc version ??! I'll lscrew my host |
| 43 |
> I guess.) |
| 44 |
|
| 45 |
Chroots and some wrapper scripts... |
| 46 |
|
| 47 |
> I would really like if there was an option on make.conf to specify |
| 48 |
> default compiler. As each of my targets have its own make.conf and |
| 49 |
> profile link, it would be very comfortable if I could tell emerge to |
| 50 |
> use the compiler specified in make.conf, so that each time I'd |
| 51 |
> cross-emerge, the good compiler for my target would be selected. |
| 52 |
|
| 53 |
Read the docs for portage. The make.conf/portage dirs used are all |
| 54 |
configurable using environment variables - hence you can have multiple |
| 55 |
profiles for different targets. It nearly works as advertised... Couple |
| 56 |
of quirks |
| 57 |
|
| 58 |
Note it won't switch compilers, but this seems very easily scripted |
| 59 |
(./setup_build_environment myquirkybuilds_2) |
| 60 |
|
| 61 |
Ed |
Archives