GCC 4.1.1 and glibc 2.4 stable on x86 and amd64

[Headrush]

Is it safe to assume that the stage tarballs for 2006.1 I see on the mirrors has been compiled with gcc-4.1.1?

Code: Select all

gcc --ver

will show you which version it is.

EDIT: It is gcc-4.1.1

I assume they are, it wouldn't make much sense to mark gcc-4.1.1 and glibc-2.4-r3 stable and release 2006.1 compiled with an older version.
I was just checking to see if the stages were updated as although close, 2006.1 was released final yet.

How does gcc --ver show if the binary packages in a tarball are compiled with a specific version of gcc?
My system is already compiled with the newer versions, I was justing looking for verification for someone else who was waiting on installing.

[thorak]

I already had gcc-4.1.1 installed, after upgrade to glibc-2.4-r3, gcc no longer works,
emerging libtool I get (On amd64):

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.

config.log says:

configure x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe conftest.c >&5
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so: file format not recognized; treating as linker script
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so:5: syntax error
collect2: ld returned 1 exit status

Any suggestions?

[novazur]

So my question is :
i can abilitate distcc after switch to new gcc for speed up ?

I tried that, but I had an error compiling 6th package (gettext), so I disabled distcc...

[rickj]

Hey, this is toooo easy. Following the Guide slavishly, just finished the

Code: Select all

emerge -eav system

and started on the world merge. It'll take a while (827 packages) but no hint of a problem, and I'm running on the system while it upgrades. Did it all with distcc running, on two systems to speed things up. Thanks for all the hard work.

One minor point, not covered in the guide. Wouldn't it be preferable to re-compile the kernel, too, just to have it match the rest of the system?

[Gergan Penkov]

Hey, this is toooo easy. Following the Guide slavishly, just finished the

Code: Select all

emerge -eav system

and started on the world merge. It'll take a while (827 packages) but no hint of a problem, and I'm running on the system while it upgrades. Did it all with distcc running, on two systems to speed things up. Thanks for all the hard work.

One minor point, not covered in the guide. Wouldn't it be preferable to re-compile the kernel, too, just to have it match the rest of the system?

i'm not sure, but I think I've had problems in the past with external modules - I think the rule is to have the kernel and the modules compiled with the same compiler - so if you use only in-tree modules there probably will not be problems with the kernel.

[didumos]

One minor point, not covered in the guide. Wouldn't it be preferable to re-compile the kernel, too, just to have it match the rest of the system?

Definately. In fact, I think someone already asked that question in this thead

Plus, it is actually discussed under the Common Pitfalls section of the guide.

[Dominique_71]

I had a moment of noobishness...

CCACHE.... We have to reset it right?

I seem to recall that after each gcc version upgrade I had to reset it.

Thanks in advance,

J

No you don't have to clear CCACHE, the cached code is indexed by (amongst other things) the timestamp of the complier binary

Edit: typo

I have another question. Will a noatime option in fstab interfere with ccache?

[rickj]

Thanks, didumos, missed that

I still think that the kernel compile should be a routine part of the procedure, rather than being left for a fix after some poor boob gets into trouble.

The pitfalls section also recommends disabling distcc. This will work, but it's horribly slow in my case. To use distcc it is only necessary to have completed the first two stages:

Code: Select all

# emerge -uav gcc
# gcc-config i686-pc-linux-gnu-4.1.1

on each host you are distcc-ing to.

[drphibes]

I am definitely going to burn a backup before moving from gcc 3.4.6 to 4.1 and rebuilding the whole works.

[didumos]

I totally agree that a suggestion of rebuilding the kernel should be part of the main instructions; I probably wouldn't have realised/remembered that it was necessary if I hadn't read this thread.

Something that I think should also be mentioned in the guide is the requirement to enable the nptl/nptlonly USE flags for the new stable glibc. I know the ebuild will warn if they aren't enabled but it's useful to know before hand so that the system build doesn't need to be restarted. Thanks go to RazielFMX in this thread for that.

[dark_knight]

Many people around say that

Code: Select all

emerge -e system
emerge -e world

aren't necessary, because of the ABI not changing between gcc 3.4 and 4.1. Since all the new features (like the nptl one) were introduced in a long period of time, they say, the updates are not too deep to require such recompiles. What do you think about it? Is really necessary to rebuild everything?

[Paapaa]

Many people around say that

Code: Select all

emerge -e system
emerge -e world

aren't necessary, because of the ABI not changing between gcc 3.4 and 4.1.

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

Warning: It should be noted that upgrading from GCC-3.4 to GCC-4.1 or greater still requires you to follow the general upgrading instructions, as GCC-3.4 and GCC-4.1 use slightly different ABIs.

slightly different == different

[CRV§ADER//KY]

the guide omits a quite important thing: doing

Code: Select all

USE="-java -X -gtk -tcl -tk -gnome -kde" emerge -e system
emerge -e world

will speed up recompilation A LOT since while rebuilding the toolchain you will skip hundreds of useless packages.

(note: the two commands are on SEPARATE LINES).

[Paapaa]

the guide omits a quite important thing: doing

Code: Select all

USE="-java -X -gtk -tcl -tk -gnome -kde" emerge -e system
emerge -e world

will speed up recompilation A LOT since while rebuilding the toolchain you will skip hundreds of useless packages.

(note: the two commands are on SEPARATE LINES).

I'm repeating myself over and over again, but:

It would be REALLY nice if Portage new the build order itself without users having to wonder what to rebuild and how many times. Portage should have a third group (in addition to system and world) called "toolchain" which is a subset of system which is a subset of world, so that:

1. If you rebuild world: first Portage builds toolchain IN CORRECT ORDER, then the rest of the system files, then the rest of world files. No need to build ANY package more than once.
2. If you rebuild system, it first builds a sane toolchain then the rest of the system files.

I have no idea if this is hard/easy to implement but the need for this seems to be very high.

[M@rijn]

It look likes GCC 4.1.1 loops while installing here, on my AMD X2 4200+ (32-bit installation) it takes 5 hours of compiling now, and it look likes the same checking ..... and compiling stuff is scrolling on the screen, anyone else had the problem?

[CRV§ADER//KY]

It would be REALLY nice if Portage new the build order itself without users having to wonder what to rebuild and how many times. Portage should have a third group (in addition to system and world) called "toolchain" which is a subset of system which is a subset of world, so that:

1. If you rebuild world: first Portage builds toolchain IN CORRECT ORDER, then the rest of the system files, then the rest of world files. No need to build ANY package more than once.
2. If you rebuild system, it first builds a sane toolchain then the rest of the system files.

I have no idea if this is hard/easy to implement but the need for this seems to be very high.

AFAIK, system IS the toolchain. you can't extract a subgroup.

for the same reason, what you're asking is not possible: packages in the toolchain normally require GTK, X, and Java, so you simply can't emerge them completely before the others - unless you're emerging them twice like now.

it would be very useful to have an "emerge toolchain" that emerges system exclusively with the USE flags in the profile and everything else switched off, so that it doesn't have any external dependency.

Another useful addition would be
emerge --toolchain world
which does
1)emerge toolchain
2)emerge -e world, except the packages in system that don't need recompilation since no USE flags had been stripped

analogally,
emerge --toolchain system
would result in a sane stage 3 without having to recompile packages twice when it's not necessary.

[Paapaa]

AFAIK, system IS the toolchain. you can't extract a subgroup.

I think system != toolchain. Toolchain is constituted of glibc, gcc, binutils, linux-headers (anything else crucial?) - a very small subset of system. System has many additional Gentoo core components which are not part of toolchain and they definitely don't have to be built before other packages.

[RazielFMX]

Just to let you all know, it's not in the upgrade guide, but you should probably rebuild your kernel after the emerge -e world. I run an x86_64 system.

emerge -e world failures and fixes for the x86_64
(I will tackle my x86 box next)

xmms-crossfade -> Unmask new version in /etc/portage/package.keywords

x11-libs/fox, and XFE -> unmerge xfe, then run emerge -a --depclean, then, try to remerge. Now, start adding things to your keyworld file... xfe and fox of course, then keep emerge -p xfe until you find all the packages you need to add.

Then you are good to go!

[psic]

Hi, weedman, the same thing happened to me, basically, I edited the make.conf, re-emerged gcc, followed all of the steps in the upgrade guide (the gcc-config, the source /etc/profile, etc.), and am now running 'emerge -ev sistem', which is (so far) going well.

A bit of an update: I did the above after changing the CHOST from i386 to i686. The first emerge -ev sistem went well until it came to gcc-4.1, which gave me an 'emake failed with profiledbootstrap' error. I then re-emerged gcc-4.1 (oh, and yes, it is indeed using the gcc-4.1) and am now doing a emerge -e sistem again, though this time I'm going through the packages slowly, about 15 at a time (anyone know it there's something wrong with this? I did emerge -pe sistem and am going through this list). I don't know if I'll try emerge -e gcc again, it takes quite a while and I don't know if it will work or not. Anyways, I hope an emerge world will fix any problems.

Anyone have any ideas about the gcc-4.1? Should I just emerge -e sistem (without gcc) followed by a emerge -e world?

[Pajarico]

Is there a way to avoid re-emerging binary packages? I have to re-install openoffice-bin, mplayer-bin, realplay, googleearth and acroread; they sum about 200 M. Also it would be cool to be able to skip packages which do not require compiling like scripts, fonts, media... but I guess this is even "more impossible".

EDIT: Also: x86 compatibility libs, java jre's and jdk's, opera...

[H-Dragon]

Hi!

I updated to GCC 4.1 following the general upgrade guide. I updated system with the new gcc, but with 10 packages left, it chose to fail on WGET.

Code: Select all

ptimer.o: In function `posix_measure':
ptimer.c:(.text+0x17): undefined reference to `clock_gettime'
ptimer.o: In function `ptimer_new':
ptimer.c:(.text+0xe2): undefined reference to `clock_getres'
collect2: ld gab 1 als Ende-Status zurück
make[1]: *** [wget] Fehler 1
make[1]: Leaving directory `/var/tmp/portage/wget-1.10.2/work/wget-1.10.2/src'
make: *** [src] Fehler 2

!!! ERROR: net-misc/wget-1.10.2 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  wget-1.10.2.ebuild, line 45:   Called die

There have been no other errors the whole time.

[j79zlr]

emerge -ev world --resume --skipfirst

Let it finish and then try and figure out what went wrong with wget. That shouldn't be a big deal as far as the system not running properly.

[rickj]

And, when you really get down to it, re-emerging the kernel sources is a bit of a waste of time too...

[orlfman]

Shit. I'm just going to build a new system to be safe. Last time I updated all my packages at once turned into a big mess. This time at least I can have a nice clean system built from scratch.

[tld]

HELP...I need to use the ~x86 version of x11-libs/fox for a 4.1.1 bug fix. It blew up my 'emerge -eav world'.

http://bugs.gentoo.org/show_bug.cgi?id=128917

If I add fox to package.keywords and try resuming that. it still wants to use the one that won't compile (x11-libs/fox-1.2.6-r3). Is there anyway I can do this without loosing the ability to resume?? I'm really far into the world recompile.

Thanks a million for any help.

Tom