markc posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 03 Jun 2005 15:39:54 +1000:
> Can anyone please help me with a downloadable /usr/bin/gcc-config ? > > I suspect if I can get a x86_64 compiled gcc-config on board then > my gcc (any version) might continue with rebuilding my system. I've sent a portage binary package direct, to avoid sending it to the list. Hope it helps, altho I'm suspecting it might be more than that. Suggestion for the future, and for everyone else on the list as well. Take a look at the portage buildpkg FEATURE. Basically, what it does is automatically creates a binary package from the files in the fake-install dir after the compile and install steps, but before the merge. Then, instead of emerging directly from the fake-install dir, portage will uncompress the tarball it just created and do the actual merge from it, thereby testing the package and ensuring it works. Because I've had this feature on for awhile, I have a copy of all the packages I have installed, often with a history going several versions back. Thus, if for whatever reason the current version doesn't work, I can quickly emerge -K the previous binary package without having to recompile it. This means I no longer have to worry about gcc or the rest of the toolchain breaking, as I can emerge -K whatever binary package I need to get compiling back working again. Note that a binary package is a standard tar.bz2 file, with the ebuild and a bit of dependency information glued onto the end of it. Thus, even if portage itself is broken such that you can't emerge even binary packages, as long as bzip2 and tar are working (or as long as you can boot off your rescue disk with bzip2/tar and the ability to mount your regular file system on it), you can simply untar the bin-pkg over your normal file system and it'll replace the bad files with its own. (Do note, however, that it'll replace files normally CONFIG_PROTECTed by portage, so backup any config files first or decompress and copy over individual files rather than untarring the whole tarball.) bunzip2 will complain about the extra stuff on the end that it doesn't understand, but it'll work with most packages you'd need to do it with (portage and its dependencies, python, bash, etc). In fact, that's pretty much exactly what the official portage rescue procedure recommends. I actually had a bad emerge of bash at one point, and had to go boot a rescue disk and untar an old bash package directly over my bad emerge. It worked. I could then boot back into my normal installation using the old bash, then remerge it to get portage synced back up with what I had, since it didn't know about my untarring and still thought I had the newer package merged. After that I was able to fix the problem and remerge the new package properly. Thus, the binpkg process saved my butt at least once. Additionally, it has been a convenient way to go back and test an old package on occasion, to see if it's the package or my config at fault, and has allowed me to do various other package debugging, such as comparing the files in the old and new packages, as well. The only problem with FEATURES=buildpkg is the space it can take up after awhile. However, I have my packages dir on its own dedicated partition of only a gig, and have to clean out old packages only every few months, when I start running out of space on the partition, so it's not a huge space hog as long as you don't let it grow forever. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
