GCC 4.1.1 and glibc 2.4 stable on x86 and amd64

[amne]

As previously announced sys-devel/gcc-4.1.1 and sys-libs/glibc-2.4-r3 are stable on x86 and amd64 now.

To upgrade gcc please follow the Gcc upgrading guide.

As it turned out in the discussion before, some questions are unclear for some users, so i'll try to make it clear here:

I want to upgrade from gcc 3.4 to gcc 4.1 - which instructions do i use?
Please follow the general instructions.

Do i really have to recompile everything?
You really really should do that, as it is the only way to guarantee your system is in a sane state.
Please also read this explanation by wolf31o2.

emerge -e world/system failed, do i have to recompile from the beginning?
I would like to stop emerge -e for a while, can i do that?
If emerge terminates due to an error or because you (accidentially or intentionally) stop it, you can run

Code: Select all

emerge --resume

it will continue the last emerge you started. However if you're half through with compiling openoffice it will still start from the beginning.
If emerge stops due to a failure, try

Code: Select all

emerge --resume --skipfirst

which resumes and skips the first package (read: the one that failed).

I want to do it using revdep-rebuild like when i upgraded from 3.3 to 3.4
Using revdep-rebuild is not as safe as really rebuilding all packages, and only worked for the 3.3->3.4 transition. It is not intended for the update to 4.1.
If you upgrade from gcc 3.3 to 4.1 it may also fail terribly using revdep-rebuild, do a full emerge -e system and world.
Again, please also read this explanation by wolf31o2.

I heard that i should do

Code: Select all

emerge -e system
emerge -e system
emerge -e world
emerge -e world

[/b]
This is not necessary, just do it once as mentioned in the upgrade guide.

I don't want to switch to gcc 4.1
This is possible and explained in the GWN
However, please be aware that older compilers are mostly unsupported as far bug reports are concerned.

So what about glibc?
Your new glibc will be installed during emerge -e system.
As with all glibc updates, once you've upgraded you should not downgrade glibc to a lower version after the upgrade.
edit: Actually glibc will refuse to downgrade anyway as this is checked in the ebuild.

If you already upgraded your gcc to 4.1 before it hit stable and only want to upgrade glibc, you don't need to recompile your system, just install the new version.

If you have further questions about the update, please post them here.

[mystified]

I'm emerging the new gcc 4.1.1. Anything special besides gcc-config, emerge system and emerge world?

Thanks!

[Paapaa]

Just keep on watching the official guide:

http://www.gentoo.org/doc/en/gcc-upgrading.xml

(There might be an update shortly...)

[mystified]

Ok, thanks. I got it bookmarked and I'll keep checking.

[tld]

Does anyone know if it's is safe to update world (and thus install glibc-2.4) before activating gcc 4.1.1 and recompiling the system?

The sticky on the Gentoo Chat forum on gcc 4.1.1 says "Users who do not wish to upgrade to GCC 4.1.1 will require a few more steps to ensure their systems are not upgraded". It doesn't say much more about it, and that confused me as upgrading gcc doesn't automatically activate it.

Tom

[amne]

Merged a couple of posts to the sticky i had prepared earlier and hidden in a sekrit place.

Does anyone know if it's is safe to update world (and thus install glibc-2.4) before activating gcc 4.1.1 and recompiling the system?

You can, but you're going to emerge -e it anyway, which will merge glibc-2.4.

The sticky on the Gentoo Chat forum on gcc 4.1.1 says "Users who do not wish to upgrade to GCC 4.1.1 will require a few more steps to ensure their systems are not upgraded". It doesn't say much more about it, and that confused me as upgrading gcc doesn't automatically activate it.

See my first post for a link to the GWN article from last week.

[amne]

I'm emerging the new gcc 4.1.1. Anything special besides gcc-config, emerge system and emerge world?

Run fix_libtool_files.sh 3.4.6 (or whatever your old version was) after emerge gcc - this doesn't happen automatically for the gcc 3->4 change. It will also be mentioned in the updated version of the guide that also contains some other small fixes, which will be online soon.

[tld]

Does anyone know if it's is safe to update world (and thus install glibc-2.4) before activating gcc 4.1.1 and recompiling the system?

You can, but you're going to emerge -e it anyway, which will merge glibc-2.4.

I was going to wait on glicbc, but it appears that glibc-2.4 is a dependency of gcc-4.1.1(??).

Tom

[amne]

I was going to wait on glicbc, but it appears that glibc-2.4 is a dependency of gcc-4.1.1(??).

I assume you've tried emerge -uav gcc, which also updates dependencies such as glibc, try emerge -av gcc, which shouldn't update glibc.

[bigbob73]

I'm already using gcc4.1.1 and glibc2.4. should i just change profiles and remove the appropriate entries in package.* (using straight x86 otherwise.)

[RazielFMX]

A friendly warning to the Gentoo user world:

Add nptl and nptlonly to your USE flags before starting the upgrade guide, otherwise glibc will not compile, it will just yell at you to do the aforementioned.

If you forget, remember to restart your emerge command with a --resume!

[R!tman]

I followed the howto, nevertheless...

Code: Select all

 emerge -1 libtool
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-devel/libtool-1.5.22 to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking libtool-1.5.22.tar.gz ;-)
>>> Unpacking source...
>>> Unpacking libtool-1.5.22.tar.gz to /var/tmp/portage/libtool-1.5.22/work
 * Applying libtool-1.4.2-archive-shared.patch ...                                                  [ ok ]
 * Applying libtool-1.5.6-ltmain-SED.patch ...                                                      [ ok ]
 * Applying libtool-1.4.2-expsym-linux.patch ...                                                    [ ok ]
 * Applying libtool-1.5.20-use-linux-version-in-fbsd.patch ...                                      [ ok ]
 * Applying libtool-1.5.10-portage.patch ...                                                        [ ok ]
 * Applying libtool-1.5.20-version-checking.patch ...                                               [ ok ]
 * Applying libtool-1.5.20-ltmain_sh-max_cmd_len.patch ...                                          [ ok ]
 * Applying libtool-1.5-filter-host-tags.patch ...                                                  [ ok ]
 * Applying libtool-1.5.10-locking.patch ...                                                        [ ok ]
 * Applying libtool-1.5.14-egrep.patch ...                                                          [ ok ]
 * Applying libtool-1.5.20-override-LD_LIBRARY_PATH.patch ...                                       [ ok ]
 * Generating ltmain.sh ...                                                                         [ ok ]
 * Running autotools in '.' ...
/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO                         [ ok ]
 * Running autotools in 'libltdl' ...
/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO                         [ ok ]
 * Removing useless C++ checks ...                                                                  [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/libtool-1.5.22/work/libtool-1.5.22 ...
 * econf: updating libtool-1.5.22/libltdl/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating libtool-1.5.22/libltdl/config.sub with /usr/share/gnuconfig/config.sub
 * econf: updating libtool-1.5.22/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating libtool-1.5.22/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

!!! Please attach the following file when filing a report to bugs.gentoo.org:
!!! /var/tmp/portage/libtool-1.5.22/work/libtool-1.5.22/config.log

!!! ERROR: sys-devel/libtool-1.5.22 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  libtool-1.5.22.ebuild, line 128:   Called econf
  ebuild.sh, line 541:   Called die

!!! econf failed
!!! If you need support, post the topmost build error, and the call stack if relevant.

Here is config.log.

[syouth]

Oh joy, oh joy. I started my upgrade. I will edit this post for a feedback..

[RazielFMX]

R!tman, try again. I had things randomly fail on me first time through. I'm now up to the emerge -eav world step...

Also, make sure you do the gcc-config then source /etc/profile. I missed that first time through and things were WAY wrong... And probably the cause of my compile failures, since the system run and libtool were smooth after that...

[Polynomial-C]

Hi,

is fix_libtool_files.sh really necessary after upgrading gcc when running emerge -e system && emerge -e world in any case after gcc-upgrade?
I don't like fix_libtool_files.sh as it was the cause for orphaned files after running it for many times on my system.

Cheers
Poly-C

[CRV§ADER//KY]

won't nptlonly break binary packages that don't support it? what are the ups and downs in enabling/not enabling it?

[amne]

is fix_libtool_files.sh really necessary after upgrading gcc when running emerge -e system && emerge -e world in any case after gcc-upgrade?
I don't like fix_libtool_files.sh as it was the cause for orphaned files after running it for many times on my system.

I assume you may run into some problems compiling if you don't, but i really can't give you an estimate how much trouble it'll be.
As far i know this is the last time you'll have to do it as gcc 4.1 does those things differently.

[Barnoid]

Code: Select all

# emerge -e system
# emerge -e world

will compile many packages twice which is a complete waste of time.

For those of you who don't want to compile packages more than once run:

Code: Select all

# emerge -pe system | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/LINGUAS.*//" | sed "s/.*/=\0/" > system.list
# emerge -pe world | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/LINGUAS.*//" | sed "s/.*/=\0/" | grep -vFf system.list > world.list
# emerge --oneshot --nodeps `cat system.list world.list`

Note: if your system.list or world.list file contains entries like

Code: Select all

=] dev-lang/php-4.4.3-r1

you need to cut away more columns (i.e. replace 'colrm 1 16' with 'colrm 1 18', for example) such that the entries all read

Code: Select all

=dev-lang/php-4.4.3-r1

On my desktop, this saves me double compilation of over 100 packages.

Cheers,
Barnoid

[Polynomial-C]

Hi,

I assume you may run into some problems compiling if you don't

I really can't imagine how, if I compile everything nearly from scratch. On the other hand, you're more experienced with this stuff than I am. I think I will just jump into cold water and try it without fix_libtool_files.sh

Cheers
Poly-C

[Vrenn]

Hi everybody

My problem is that I cant compile 2 GB over night, impossible. Can I upgrade system and world, stop world and resume it every following day? Can I leave gcc 3 paralell until emerge --resume is done? And should kernel-recomb be right after system?
Thanks for your help.

[Barnoid]

As I have suggested above, avoid compiling packages twice. If you generate the two files (system.list and world.list) as described in my earlier post, you can split these two files manually into smaller files containing only a few packages (say, system.list.1, system.list.2, ..., world.list.1, world.list.2, ...) and then run

Code: Select all

# emerge --oneshot --nodeps `cat system.list.1`
# emerge --oneshot --nodeps `cat system.list.2`
...
# emerge  --oneshot --nodeps `cat world.list.1`
# emerge  --oneshot --nodeps `cat world.list.2`
...

Cheers,
Barnoid

[Aszrael]

...And should kernel-recomb be right after system?

I would really recommend that

[R!tman]

R!tman, try again. I had things randomly fail on me first time through. I'm now up to the emerge -eav world step...

Also, make sure you do the gcc-config then source /etc/profile. I missed that first time through and things were WAY wrong... And probably the cause of my compile failures, since the system run and libtool were smooth after that...

I actually did

Code: Select all

source /etc/profile

I found out libtool does compile with 3.4.6, only 4.1.1 gives me headaches.

BTW, I only have that problem on amd64, libtool compiled fine with 4.1.1 on my x86.

Any suggestions?

EDIT: libtool doesn't seem to like the combination gcc-4.1.1 and LDFLAGS="-W1, -O1". With disabling LDFLAGS I could finally compile libtool!

[Sachankara]

won't nptlonly break binary packages that don't support it? what are the ups and downs in enabling/not enabling it?

NPTL is fully backwards compatible with LinuxThreads. At least I've never had a problem with binary only stuff.

[amne]

Code: Select all

# emerge -e system
# emerge -e world

will compile many packages twice which is a complete waste of time.

As said before, only this way you can be sure everything works fine, even if this consumes a bit more time.

I really can't imagine how, if I compile everything nearly from scratch. On the other hand, you're more experienced with this stuff than I am. I think I will just jump into cold water and try it without fix_libtool_files.sh

Tbh, i just can't tell you if it may work or not. To make things work fine, you should do it. If you don't but are aware what's possibly going to happen, give it a try.

My problem is that I cant compile 2 GB over night, impossible. Can I upgrade system and world, stop world and resume it every following day? Can I leave gcc 3 paralell until emerge --resume is done? And should kernel-recomb be right after system?

Yes, stopping and resuming should work fine. As for the kernel, the only problem i am currently aware of is that modules and kernel need to be compiled with the same version, e.g. if the kernel is compiled with gcc 3.4 and ndiswrapper with 4.1 it won't load. So it's probably easiest to recompile your kernel quite soon and then also recompile all external modules such as ndiswrapper, kqemu etc.