No-rebuild-toolchain?

[Incomplet]

Here's my basic problem: I have an older system and it takes significantly more than 24h to rebuild glibc. I really don't want to have to rebuild my toolchain on this machine for any reason.

I figured out how to use /etc/portage/package.mask to stop it from trying to download and install a new version of glibc, but unfortunately it's still trying to rebuild them (for my flag settings and possibly locales). Is there a way to disable that, and what exactly do I have to disable to cover glibc/gcc/binutils?

(note: compiling other things isn't a big problem; even xorg finishes in a reasonable time, just not the toolchain)

EDIT: Ok I tried adding --rebuild-ignore gcc binutils glibc to EMERGE_DEFAULT_OPTS and adding them to /etc/portage/package.mask, and emerge -uDN world still wants to rebuild all three

[VinzC]

Really old systems deserve either a binary distribution or using distcc for the compile job. In the latter case the more hosts, the faster. I've already run into a similar situation (though it was with a modern machine) but ended up leaving the compile process do its stuff anyway. Too much of a hassle otherwise.

Note that distcc is there only for compiling. There are still a number of operations that do run on the target host, like linking and preprocessing.

You can also replicate the complete system in a chroot environment on a fast machine and have the complete build run from there and then copy it back (e.g. using tar) onto the older host. That'd be the fastest way IMHO.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763
“Wow! I feel root”

[Incomplet]

heh, my main problem with binary distros is bloat. If I could figure out a reasonable way to compile a stage3 with uclibc and busybox and get it back onto this machine in one piece I'd be all up for that. Of course, then I run into the question of compatibility with ucilbc, and I have no idea what sorts of stuff that might break.

The other machine has like 750GB HD most of it unused, so I could probably float a minimal gentoo on it for compiling stuff and then just use -K. I was thinking of using buildroot, but I'm not sure that I could get portage to play nice with it.

[VinzC]

I once built a uClibc target ATOM machine with the crossdev toolchain. Works pretty well though I ran into a couple of catches. But none that I couldn't solve. You also have the Qemu/KVM method if you prefer native compiling.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763
“Wow! I feel root”

[Incomplet]

EDIT: scratch most of that.

EDIT: scratch all of that. The other machine isn't nearly as fast as I thought it was. Setting it up would probably be a larger pain than just starting from scratch again and compiling everything on this machine :\.

[Veldrin]

if portage want to rebuild them, there usually a good reason. not doing so will break your system, sooner or later.

on path that hasn't been mentioned here is the gentoo tinderbox, which provides binary packages.
Downside, you have to accept the keywords and optimization they chose.

So far, I only used tinderbox to recover a broken system, but I guess it can also be used as a BINHOST.


just an idea
V.
_________________
read the portage output!
If my answer is too short, just ask for an explanation.

[Incomplet]

You know, after I started over again I noticed something odd about memory usage. After doing nothing but untarring the stage3 and portage, I only had about 500MB of memory left. That's after a clean boot.

The last time I tried to compile the kernel it failed after spamming warnings left and right (stupid install disk script sets my clock back to 1970 every time I boot since network won't autoconfig by itself) and took literally like 24 hours to compile before failing.

Now, after a few reboots to clear memory while getting the base system set up, it only took like maybe an hour to compile the kernel. *sigh* on to other problems.

[Veldrin]

500MB out of how much? how did get that number? does it include the caches/buffers?
By default, linux uses all memory available for caching. If an application needs memory, it can just free some cached data. the problem is, that the default number about free/used memory you get includes those caches, therefore it tells you that much more memory is used, that actually is.

if you use free to calculate the memory usage, then the line you should be interested in is starting with "-/+ buffers/cache:" which gives you the actual memory usage.

V.
_________________
read the portage output!
If my answer is too short, just ask for an explanation.

[Incomplet]

Out of 1.5GB. It was also starting to swap significantly. Since I've gotten my system running on it's own kernel, now when I run free -m it's only using about 400MB and no swap, and that includes all the buffers and cache, and I've done a good deal of emerging since boot.

In retrospect I think the long compile times were an artifact of the kernel resetting my system clock, and had nothing to do with memory caching. When things were going bad it took the kernel nearly 24 hours to compile and then it failed. When I compiled the kernel I'm using now it took maybe 45 minutes. I have no idea why it eats my memory when I boot from CD, however.

[John R. Graham]

Possibly because you failed to enable swap before entering the chroot? Unless you have tons of RAM, this can have a significant impact on performance.

- John
_________________
This space intentionally left blank.

[Incomplet]

Nah, that'd be easy though. I did forget to enable swap one time, and there was another time when I thought I enabled it but then top showed no swap size. However, the last few times I had to boot from CD I always made sure to do mkswap almost before I did anything else.

That time swap was definitely working, and linux was beginning to use hundreds of MB of it, too. Booting from HD it hasn't used swap yet that I know of and I have 1GB+ of free mem even after buffers and caching. Almost the full 1.5GB is free minus buff/cache.