While upgrading gcc-3.3.5-20050130 to 3.4.5 I've used the "Gentoo Linux GCC Upgrade Guide". I took the "emerge -e" way, and I've noticed a small problem. Typically the /boot partition on Gentoo/sparc is located on /dev/hda1, while / (root) is located on some other partition - in my case /dev/hda7. When upgrading gcc the "slower" way, first the system is rebuilt, the the world is rebuilt (both with --empty-tree). However, during this process silo (the boot loader) is rebuilt and reinstalled. My situation was that while installing the system I've created a /boot/silo.conf file, but I *haven't* touched the /etc/silo.conf file... Which led to the (more or less) obvious - the machine wouldn't boot anymore. So I needed to use LiveCD to reinstall silo manually with the correct configuration file. So, I'd like to suggest to put additional warning in the docs, chapter 4, "Common Pitfalls". The proposed text follows: --- BEGIN If you have a sparc machine and your /boot directory is on a different partition than the root (/) directory, make sure that after running "emerge -e world" you re-run silo. Otherwise you may find that your machine wouldn't boot anymore correctly, because during "emerge -e world" silo is recompiled and reinstalled. The command you need is the same as documented in the Gentoo Handbook: # silo -C /boot/silo.conf --- END I don't know if a similar warning should be added for lilo users, because I exclusively use grub on my other arches (x86 and amd64), so I haven't had any problem with upgrading gcc there.
sparc team, is this correct?
I know you guys like your generic-approach docs and i'm fine with them, but the gcc upgrade guide as it is won't work right for the sparc upgrade. Let me explain, usually in the gcc-3.3 -> 3.4 upgrade the big binary break-my-momma issue is libstdc++, but in sparc there's a couple of additional issues as documented in http://gcc.gnu.org/gcc-3.4/sparc-abi.html Long story made short you HAVE to emerge -e world, you can't revdep-rebuild your way thru it since there's parameter-passing changes too in the ABI. Granted, they're the complex type and probably 99% of the users will never hit that, but it's possible to do so anyway. The other issue is the mention of libstdc++-v3, i keyworded that as sparc stable just a a precautionary messure, but it's really not necessary since we don't have binary-only ebuilds that use libstdc++, except opera, but it's static so it doesn't matter. The silo note can be added, even though the ebuild already mentions that. I'd add the -f option to it too since the user could be hitting a legitimate upgrade.
Also forgot to mention that the gcc/toolchain upgrade depends on the 2006.0 profile, older (<=2005.1) profiles don't allow for gcc-3.4 to upgrade without some serious user intervention (package.unmask). So this is more suited to a sparc 2005.1 -> 2006.0 upgrade guide rather than the gcc one IMHO.
Created attachment 78463 [details, diff] gcc-upgrading.xml.patch What about this one? Only mentioning the need to `emerge -e world`, no SILO specific changes, no SPARC profile stuff...
Also CC-ing co-authors/editors of the guide.
In CVS, thanks.
Ok, thanks. That clarifies things a bit. I've already done a test run with the 2006.0 profile indeed, in order to update the compiler and kernel at the same time. But during the process I've found a small problem which I reported here. For me it was not addressed properly. During "emerge -e world" silo WILL BE rebuilt using its defaults, with a slight chance for making the system unbootable. I've proposed a small warning (yes, it's sparc specific) for any people that might encounter the same problem. I'd like to point out that "4. Common Pitfalls" already contains references to "i686", so those are arch specific as well... And the precedence exists. If you feel that this is valuable, please add just one additional warning. OTOH if you think this is not worth the trouble, just close the bug. Regards,
After some talk with SPARC developers, I've added a note that you might have to re-run SILO. Thanks for reporting.
