Upgrading your system to gcc 3.4(.4)

[Akaihiryuu]

I just noticed on the one system so far that has had GCC 3.3.6 removed, it still has a /usr/share/gcc-data/i686-pc-linux-gnu/3.3.6 directory. I did equery to see if this directory belongs to any packages and it doesn't. The 3.4.4 directory does belong to sys-libs/gcc-3.4.4 though. Was this directory just left because of config file protection, and is it safe to delete? Are there any other things left hanging around from 3.3.6 that can be removed?

[katharsis]

Just an idea:
I don't know if stuff like grub and memtest86 will do it automatically if necessary, but I think it would be a safe idea to mount /boot before the emerges, especially if u want to run it unattended/over night/whatever.

Another (obvious) hint for newbies without a flat rate isp is to run emerge -f world before the actual emerge -e so the box can be offline during the rebuild.

Maybe this should be added to the guide, I don't know .

[guru245]

This is what I've done.

# emerge -uv gcc
# gcc-config i686-pc-linux-gnu-3.4.4
# source /etc/profile

# emerge sys-libs/libstdc++-v3 (I forgot add --oneshot option)

# emerge -e system
# emerge -P gcc
# emerge -e world
# emerge -e system

Prior to going on emerge -e world, I can't find gccmakedep. It's gone. What's the matter?

[paul555]

I followed the guide but during emerge -e world anjuta gave me that error :

Code: Select all

checking command to parse /usr/bin/i686-pc-linux-gnu-nm -B output from i686-pc-linux-gnu-gcc object... ok
checking for objdir... .libs
checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar
checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib
checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip
checking for correct ltmain.sh version... no

*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.20, ltmain.sh = 1.5.18) ***

Please run:

  libtoolize --copy --force

if appropriate, please contact the maintainer of this
package (or your distribution) for help.


!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/anjuta-1.2.4/work/anjuta-1.2.4/config.log

Any clue?

[Exil]

Smoe files have differnet versions

Code: Select all

*** (libtool.m4 = 1.5.20, ltmain.sh = 1.5.18) *** 

emerge package with them or emerge --resume --skipfirst and reemerge anjuta after it.

[sigmalll]

I don't really know a lot about compilers or GCC. Is there a page where things are described for dummies like me?
I only want to know if it is worth the time to recompile my whole system or if it is not important at all.
My mind circles around the following questions: Will this version be standard in the gentoo future? If not why not? Why did the devs chose
not to make it standard after it stabilized?

It will be the standard compiler from now on (until a new compiler comes out), if you don't upgrade you may have problems getting support on the forums when packages fail to compile in the future.

[gschinkel]

Just a quick note on nget-0.26 and the new gcc: it doesn't compile because of template issues. A quick way to solve it is to emerge unstable nget-0.27.

[paul555]

sorry my mistake i shoulded search the forums first i found that error and bug in bugzilla.Now i emerge --resume --skipfirst and i will deal with it later

[incubator]

Well, for those not wanting to stick with both gcc 3.3.x and 3.4, I found out that , in my case, I already had gcc 3.4 as my only compiler installed (dont know why that happened, been like that for some time)

So, I just did the quick & dirty revdep-rebuild way wich rebuilt a lot of packages, meanwhile I cleaned up sstuff I did not need/want.
(as a KDE lover, I completely removed any gnome libs and derivatoves , also removed php, ruby and tcltk, wxGTK, pygtk support and I find my system responds faster, its a lot lighter too )

I recompiled every package that needed relinking etc and lo and behold, gcc 3.3.6 no longer shows up as NS during an emerge -pv world

(hint for the finetuners: equery depends <packagename> is a beauty)

[znmeb]

[1] http://www.gentoo.org/proj/en/base/x86/ ... -guide.xml

I just looked through the instructions. Why do you have to do *both* "emerge -e system" and "emerge -e world"?? Doesn't the "emerge -e world" emerge both system and the packages you've added onto system? It looks to me like you're emerging "system" twice!!

[Sho]

@znmeb: Because you want emerge -e world to use a gcc34-based toolchain - which is build during emerge -e system.

Read the thread. It's been covered.

[JohnHerdy]

After revdep-rebuild -X --library libstdc++.so.5 -v affected ebuild were updated including dev-lang/python-2.4.2, however if I run revdep-rebuild -X --library libstdc++.so.5 -v again it wants to update dev-lang/python-2.4.2 again (and again and again and ....).

Could someone else please check if they have the same behaviour? Is it safe to uninstall sys-devel/gcc-3.3* or will this result in a broken python/portage?


Also I'm interested if someone who has done emerge --oneshot sys-libs/libstdc++-v3 and emerge -aC =sys-devel/gcc-3.3* can do a emerge --depclean -vp and see if sys-libs/libstdc++-v3 is in the list.

Thanks!

[RiverRat]

Sorry for asking this while it was hinted at before, but I think it hasn't really been explained yet.

No matter which method I use to upgrade my GCC, I can't understand why I shouldn't be able to set GCC 3.4.4-specific CFLAGS as soon as I've executed this piece of code:

Code: Select all

# emerge -uav gcc
# gcc-config i686-pc-linux-gnu-3.4.4
# source /etc/profile

After this is done, GCC 3.4.4 is present and the default compiler, used in every following emerge (right?).
I understand that some programs might still rely on the old version, but that shouldn't stop me from already using the new flags when compiling stuff, right?

In fact, after studying the GCC 3.4.4 documentation, it appears that -O2 already includes some of the new C flags (like -funit-at-a-time). So this means that, even if you don't specifically add GCC 3.4.4 C flags yourself, everyone using -O2 is already implicitly using some. Doesn't this mean it's fine to set them as soon as gcc-config has set GCC 3.4.4 as default compiler?

This was not just hinted at but I answered it in full here: https://forums.gentoo.org/viewtopic-p-2 ... ml#2925003

[JohnHerdy]

Another question;

I use the -X parameter with revdep-rebuild (recompile based on package names, not exact versions), however the newer version have non-installed dependencies but revdep-ebuild add --nodeps to the emerge command. Is there any undocumented parameter (in the newer version) that removes the --nodeps?

Thanks!

[frilled]

I followed the migration guide. I guess I shouldn't have

Basically I fear, recompiling two boxes (~570 and ~820 packages) was mostly in vain. Why? Because during the world recompile, gcc-3.3.6 is re-merged - and the 3.3.6 ebuild *does* set the active gcc back to 3.3.6. So basically 700 of those 800+ packages were simply compiled with 3.3.6 again instead of 3.4.4, making this a massive waste of resources :/

Prove me wrong, but I am just watching a box that has ~300 packages to go use using 3.3.6 to compile OpenOffice.org 2.0. Which takes about 6 hours. In vain.

[thomasvk]

I think it shouldn't happen with the updated guide. I closely watched the whole updating process and GCC didn't switch at all (following the updated guide).

[Sho]

Ditto. Went well on two boxes with the updated guide.

[frilled]

Yeah, I'll try AGAIN with merging the library first

Looking forward to all the servers

[thomasvk]

Why would you recompile everything on servers? Unless it fixes some important security issues, wouldn't it be useless to upgrade on servers?

[frilled]

Because revdep-rebuild failed on me so many times I don't really consider it an option. And clinging to an old gcc is also not really an option.

[henrikgentoo]

after careful reading, all the messages in this forum, I still don't know when I should run genkernel to take advantage of the new gcc 3.4.4 compiler ?

Henrik

[Pasketti]

I tried following the upgrade guide, but the version I had printed out was the original one that had the libstdc++ install in the wrong place. So of course, when I emerge -e system, it re-installs gcc-3.3.6 and resets that as the default compiler. Fortunately, I caught it pretty quickly.

What I wound up doing was this:

# upgrade compiler
emerge -u gcc
# get list of packages to recompile
emerge -peu world > worldmerge

#edit worldmerge file into a shell script
#that individually emerges each package
#via emerge =packagename-version,
#then run it
./worldmerge

#edit worldmerge script to recompile everything
#that was installed before glibc, and run it again
./worldmerge

#revdep-rebuild for old library
revdep-rebuild --soname libstdc++.so.5

#unmerge old compiler
emerge unmerge gcc-3.3.6

#revdep-rebuild for anything else
revdep-rebuild

#recompile the kernel
make clean && make bzimage && make modules modules-install

#install new kernel and reboot

It all seems to work ok. revdep-rebuild gives me a clean bill of health. I don't have any binary packages, so I didn't install libstdc++-v3.

[frilled]

Well, you "take advantage" after setting 3.4.4 as default.

After that (and probably compiling a lot of stuff *gg*) you will most likely want to compile the kernel with the new gcc, too. That's when genkernel comes in. No more, no less.

[RiverRat]

I followed the migration guide. I guess I shouldn't have

Basically I fear, recompiling two boxes (~570 and ~820 packages) was mostly in vain. Why? Because during the world recompile, gcc-3.3.6 is re-merged - and the 3.3.6 ebuild *does* set the active gcc back to 3.3.6. So basically 700 of those 800+ packages were simply compiled with 3.3.6 again instead of 3.4.4, making this a massive waste of resources :/

Prove me wrong, but I am just watching a box that has ~300 packages to go use using 3.3.6 to compile OpenOffice.org 2.0. Which takes about 6 hours. In vain.

Okay, according to gcc-config the following happens:

Code: Select all

gcc-config --use-portage-chost  Only set to given profile if its CHOST is the 
                                same as that set for portage in /etc/make.conf
                                (or one of other portage config files...).

I looked through the ebuilds and it seems that some of the older ones actually do call gcc-config in some situations to change the default compiler. These all appear to be dated and upgrading to the latest gcc ebuilds for the given tree (3.3.x or 3.4.x) should resolve the issues. For example, in the gcc-3.4.1-r3.ebuild it says:

Code: Select all

        if [ "${ROOT}" = "/" -a "${CHOST}" = "${CCHOST}" ]
        then
                gcc-config --use-portage-chost ${CCHOST}-${GCC_RELEASE_VER}
        fi

The ones that I found that perform this are: gcc-2.95.3-r9.ebuild, gcc-3.2.3-r4.ebuild, gcc-3.3.2-r7.ebuild, and gcc-3.4.1-r3.ebuild.
According to the most recent ebuilds (/usr/portage/sys-devel/gcc/gcc-{3.3.6,3.4.4-r1}.ebuild) this does not happen.

[figueroa]

I took the "faster method" approach using revdep-rebuild and had an emerge failure with one of the packages 80% through. After fixing the problem, if I rerun revdep-rebuild according to the instruction provided along with the failed emerge, it starts all over again. Can I use emerge --resume instead?

If NOT, can I switch in midstream and use the "safer method" now?

Any other suggestions? I'm on my third run through the entire process using revdep-rebuild so I was a little frustrated watching it start all over again for the third try.