GCC 4.1.1 and glibc 2.4 stable on x86 and amd64

Message

Lloeki · Post by **Lloeki** » Thu Oct 26, 2006 7:58 am

I have -O2 -pipe -march=pentium-m so I bet that's not because -fomit-frame-pointer nor -march=pentium3. check your /tmp or /var/tmp (free space?), -pipe make lots of things stay in-mem while not having it will use temporary files on disk.

piggie · Post by **piggie** » Thu Oct 26, 2006 9:52 am

I think you are right.
It just failed again during emerge -ev system.
Plenty of space for /tmp so I dont think its a space issue.

/dev/hda3 38978276 4048552 32949716 11% /

piggie · Post by **piggie** » Thu Oct 26, 2006 11:24 pm

Turned my ram down to 100mhz from 133mhz and emerge -ev system worked fine.
Trying emerge -ev world now.

cazort · Post by **cazort** » Mon Oct 30, 2006 2:11 pm

I am a bit upset with the gentoo developer community for marking gcc 4.1 as stable.

I just switched to 4.1 following all the directions to the letter and the result has been far from "stable". emerge -e system worked fine, but when I ran emerge -e world, I ran into one problem after another.

I have had 3 builds so far that straight up failed to compile. When I read through the database, *ALL* of these build problems are ones that hase bugs that have been reported for at least a week, and that have had 5+ people reporting or watching the bugs. Each case is different--some of the bugs have patches that fix them or can be fixed by updating to an unstable version. Other packages I skipped over with "emerge --resume --skipfirst". But I am still not even halfway through the merge!

This has become a royal nuisance for me. If I run emerge -e world without it stopping, it takes around 48 hours for me. At this rate this whole process is going to take me over a week. And in the meanwihle, a number of programs I use daily are straight-up broken until they and their dependencies re-emerge.

Normally gentoo has been pretty good about not marking things stable until they actually ARE stable. 4.1 may be stable as itself but it caused a cascade of failed ebuilds on my system!!!

ARGH! I am grumpy!

Lloeki · Post by **Lloeki** » Mon Oct 30, 2006 3:17 pm

STFF

all the issues you mention are taken care of in that thread (and ideally, its thoroughly updated first post)

cazort · Post by **cazort** » Tue Oct 31, 2006 1:03 am

While that page is interesting for me to read, it would have been nice if I had known about that *BEFORE* I updated my system. The official documentation (and the fact that gcc-4.1 is marked stable) gives the impression that I would not run into so many packages that fail to compile, except in a few random improbable cases. I'm on my fourth failed package, and so far, all of them have been fairly "mainstream" ones...i.e. libwww, fox, cyrus-sasl...

In the past, when I've run stable on gentoo I probably run into one package that fails to compile one out of every 10 times I do an emerge -e world...or perhaps less often. I dunno? I know that an upgrade introduces unworked-out-problems but the question is, why in the heck was it marked stable if there are so many issues still?

Lloeki · Post by **Lloeki** » Tue Oct 31, 2006 9:17 am

that I would not run into so many packages that fail to compile, except in a few random improbable cases

well, making a generality based on your personal experience seems a bit overreacting.

my (and judging from the few complaints in regard to the total number of gentoo users, others too) upgrade went smoothly (and without the thread I mentioned: I followed the official gcc upgrade guide), with only 5 or so packages failing (which I named up in this very thread) of about ~800. this is far less than I expected since, after all, this is a major (gcc3->gcc4) version number upgrade of a highly critical component of the system. marking it stable doesn't make it perfect.

And in the meanwihle, a number of programs I use daily are straight-up broken until they and their dependencies re-emerge.

As you've certainly read in the thread, this was not gcc-4.1 in cause, but glibc-2.4 upgrade. this kind of thing happening is obvious on ABI changes, and this was only c++ programs which were affected. there is really no other solution than 1. do the upgrade and willingly wait for the end of rebuilding. or 2. postpone the upgrade to a more appropried time. that is, if you wished to upgrade at all.

btw, I didn't have any problems with cyrus-sasl nor libwww.

cazort · Post by **cazort** » Tue Oct 31, 2006 2:43 pm

Well, it worked out well in the end!

I think that if the guide had said: "Expect at least 5 or packages to fail building, just do emerge --resume --skipfirst" I think that would greatly improved the guide. I've used gentoo for a few years, and I've updated gcc before (I went through the 2-->3 transition), and a number of other major changes, and never had so many packages fail to build before, it kinda threw me off. I think when the guide says to run:

Code: Select all

# emerge -eav system
# emerge -eav world

And then the guide just ends, no mention of anything that can go worng...that suggests that it should be very smooth at this point. Maybe I'm just stupid for not realizing that there would be so many failed packages, but I'm not an expert on compilers and libraries and I don't understand why some updates break things and other updates don't. And many people using gentoo and that guide is going to have as much experience as you or I...I remember how I was about 3 years ago when I first started using gentoo...this sort of thing would have been much more of a nuisance. I think warning people in the official documentation is important...I read that whole document over and over before starting to make sure it was ok, and I feel like I should have been warned more...

Maybe it's my fault for not checking the forums in more detail? I usually only go to the forums after I get stuck though...

amne · Post by **amne** » Tue Oct 31, 2006 4:02 pm

It says at the end of the guide, under Frequent Error Messages:

If a package fails during emerge -e system or emerge -e world, you can resume operation with emerge --resume. If a package fails repeatedly, skip it with emerge --resume --skipfirst. Don't run any other instances of emerge in between or you will lose the resume information.

DLCool · Post by **DLCool** » Fri Nov 03, 2006 1:17 am

Hi all.
After upgrading to gcc4.1.1 I can't emerge fluxspace.
fluxspace errors:

/usr/include/features.h:154:1: warning: this is the location of the previous definition
PythonInterface.cc:259: error: extra qualification 'PythonInterfaceModule::' on member 'PythonInterfaceModule'
PythonInterface.cc:269: error: extra qualification 'PythonInterfaceModule::' on member 'PythonInterfaceModule'
make[1]: *** [PythonInterface.lo] Error 1
make[1]: Leaving directory `/var/tmp/portage/fluxspace-0.0.3-r1/work/fluxspace-0.0.3/src'
make: *** [all-recursive] Error 1

!!! ERROR: x11-misc/fluxspace-0.0.3-r1 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_compile
ebuild.sh, line 937: Called src_compile
fluxspace-0.0.3-r1.ebuild, line 24: Called die

The Box · Post by **The Box** » Sat Nov 04, 2006 6:56 pm

Hello,
I thought I would just post some things to try and help out. I'm kind of a newbie user and I think the mistake I made when upgrading could possibly be avoided with a couple more commands before starting the upgrade process. Please read and follow the upgrade guide commands in order after doing your search for the current version of GCC you have. If you don't follow the upgrade guide exactly you might end up borking

your system.

The first one would have to be done before anything in the GCC upgrade guide in the general section. Pretty simple command, but it will let you know which version of GCC you are currently running before you start the upgrade and might make a difference when you run fix_libtool_files.sh.

Pretty basic:

Code: Select all

gcc-config --list-profiles

In my case I ran:

Code: Select all

fix_libtool_files.sh 3.3.6

instead of

fix_libtool_files.sh 3.4.6 {example from the guide}

I hope this helps somebody, because it took me a while to figure out. Since I'm already posting kind of long I figured I mention something kind of funny. It's also the reason I overused the word "bork"

in this post. When I originally searched and found this thread I actually searched on the quick search using the keyword "borked"

. I thought it was kind of funny!

This whole thing is forcing me to finally learn cron and keep all my machines more up-to-date.

Good luck and let me know if this helps you.

The Box · Post by **The Box** » Sat Nov 11, 2006 4:15 pm

I don't mean to troll or anything, but I have some more to add.

The fix I posted above seems to have worked along with the tip from the end of the upgrade guide about doing a --resume --skipfirst on any packages that fail to rebuild.

There is one more thing that I'm trying to figure out. It seems everthing is working, but I keep seeing some messages about extending ACLOCAL and almost every build process is complaining about certain variables in the build process. When I figure out what this is I'll try to post back, but it hasn't caused any problems yet.

Also I would like to request that if anyone is still experiencing problems, that they try out the fixes above so we can figure out a fix that works for everybody and mark this thread solved.

Also there is a thread above with more clear instructions on this issue, but I didn't notice it because it's under an acronym of STFF?
http://forums.gentoo.org/viewtopic-t-49 ... ight-.html

hielvc · Post by **hielvc** » Sat Nov 11, 2006 4:58 pm

Or you can go here An emerge wrapper for more correctly building the toolchain

The Box · Post by **The Box** » Sat Nov 11, 2006 10:16 pm

Thanks for the tip. (seriously, not sarcastic)

Now that I'm about half way through both threads I'm not really sure which way to go. It seems the STFF thread looks a lot more like the upgrade guide and follows what I was originally trying to accomplish which is making sure that everything was correctly working and updated before upgrading GCC and the like. At the same time it also appears that this could all be automated in some ways and done more correctly by some opinions by using the emerge wrapper script you suggested in your thread.

It all leaves me asking this: Can I please have a definitive opinion from the powers-that-be on which way is the "best..." way to go?

I'm still pretty inexperienced in the ways of Gentoo after more than a year of serious use. At the same time I'm not afraid to read man pages and the like and I think I'll probably read both threads entirely before trying anything and then post my opnion if it's still valid by then. Still I'm afraid that my opinion would be less helpful than that of a more experienced user so help me out and maybe I can save a little time and read something more useful like some man pages or the wonderful documentation here on the Gentoo site.

Once again thanks for the reply...

hielvc · Post by **hielvc** » Sun Nov 12, 2006 7:19 am

You say your half way thru. What exactly are you doing ? If you'ra half way, you probalbly dont need either script.

With gentoo you have choice. Its like skinking a cat or being the cat, theres several ways of skining it and you get to chose.

In regardes to emwrap.sh it takes most of the emerge flags The ones it doesnt take are a, v. t. Use emerge for them. But If you have specfic questions post em in the apropriate thread.

Luck

rickj · Post by **rickj** » Mon Nov 13, 2006 4:19 pm

For what it's worth, I've done gcc 4.1 updates both using the method of the official HOWTO, and using heilvc's excellent emwrap.sh script. Both seem to work well and leave the system stable.

The Box · Post by **The Box** » Sat Nov 18, 2006 6:23 pm

hielvc
Everything seems to be working, and I have tried different methods on each machine in succession with varying degrees of success on all.
(when I was speaking of half-way-through I was referring to reading the threads because they are very long, but I learned to skip a bit better even if it might be a little dangerous when it comes to picking up on that one thing that helps you.)

Speaking of that one thing I still have something going on and I'm going to read through the rest of this thread and search for another to try to solve it. As mentioned before everything with my update goes great for the most part using whatever method, but I'm getting ACLOCAL errors that I saw mentioned earlier in this thread and I didn't notice any clear solution. The errors do not cause any build to fail directly, but they show up quite a bit. I'll try to pull some out of my logs and post them, but I'm pretty sure this was already done earlier in this thread. Maybe just give me a bump on the brain if I'm missing the solution or explanation of why these errors about ACLOCAL exist. Really just makes me a little nervous not knowing what they are.

After reading through a good deal of info documentation about extending aclocal, I'm still at a bit of a loss.

libero · Post by **libero** » Mon Nov 27, 2006 10:12 am

Hi

I've been writing my own tune-up / maintenance script here:

http://www.celebrazio.net/tech/unix/gentoo_maint.html

As shown, it's mainly for my own sanity but good to share, esp. with this group.

This time, my objectives of the maintenance were mainly these:

* Review USE flags and CFLAGS, other emerge settings.
* Upgrade kernel
* Upgrade to modular X
* Upgrade to GCC 4.1
* Add cool tools: KDE Basket, Eclipse SDK, etc.
* Remove obsolete, redundant crufty packages.
* Do the Java Upgrade, shown here: Gentoo Java Upgrade
* Emerge everything with the new toolchain, kernel, and USE config.
* Fine-tune the maintenance procedure a little.

Even with all this stuff, and because it's a pretty sound method, and I refer to most of the requisite Gentoo guides, the script went 95% soundly again. Definitely recommended, I avoided loops of potential time sink.

Let me know if there are any obvious omissions, but in the end, it's just a manual guide. Do not attempt to copy the commands verbatim, or you'll have trouble. Think before executing each step.

Good luck

Leo

Lloeki · Post by **Lloeki** » Mon Nov 27, 2006 2:13 pm

Leo,

well, that's one kind of a thing I wished I saw much more often: a living experience (besides my own) that when things are thoughfully considered beforehand, maintaining a gentoo system is moslty hassle-free.

props to you

libero · Post by **libero** » Tue Nov 28, 2006 9:37 am

hey Lloeki;

Thanks for the props.

to those who consider careful thinking a hassle, I guess Gentoo is actually not hassle-free.

But to those like me who enjoy the challenge of careful thinking, then Gentoo is ice cool.

It is sometimes alarming to read some of the disastrous and dire forums postings about various trouble that has sprung up. But for me, following this careful process, I have never run into big trouble. I would even go so far as to suggest that Gentoo do a "tune-up" or "maintenance" handbook, in addition to the "install" handbook which is so famous. Because after so much help in going step-by-step through the install, the average user (like me) is kind of left out in the naked open as to how to maintain the system over the next months and years.

So I created mine to satisfy my own requirement for a maintenance sanity check step by step guide. And of course now I realize that like the "install" guide, this process that I made is also changing a bit here and there with each release and new version of any key package, so that's where the careful thinking becomes critical every time.

Cool

Leo

mvc · Post by **mvc** » Sun Dec 03, 2006 4:50 pm

hi,
I don't know why, the upgrade from gcc-4.0.3 to gcc-4.1.1-r1 doesn't create the g++ executable (or symlink). It creates gcc though. The result of that is that my system only compiles c now, unless I swich back to 4.0.3 with gcc-config. When I switch to 4.1.1 it removes the g++ executable again. I've searched the forums and bugs and didn't found anything related to this. Anyone knows how can I trace this down? Thanks

burn · Post by **burn** » Mon Dec 18, 2006 7:13 am

Hey,

I'm trying to update to gcc 4.1 and after compiling for a while it will crash and my laptop will cycle off. From what I can tell I don't get any error messages. I ran script to log it and here are some parts of the log:

Code: Select all

Here is how the USE is like for the compile:

[ebuild  NS   ] sys-devel/gcc-4.1.1-r1  USE="fortran gtk nls (-altivec) -bootstrap -build -doc -gcj (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB

Code: Select all

It dies once it gets to this point:

....

stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c   -O2 -march=i686 -pipe -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc/build -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc/../include -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc/../libcpp/include     -o build/genattrtab.o /var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc/genattrtab.c

stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c   -O2 -march=i686 -pipe -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc -I/var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/gcc

Anyone have any ideas?

Crimson Rider · Post by **Crimson Rider** » Mon Dec 18, 2006 10:12 am

I've been trying to do this, but it completly broke my toolchain.

This is the error I get

Code: Select all

checking whether the C compiler (gcc -O2 -pipe ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

!!! ERROR: sys-devel/gcc-4.1.1-r1 failed.
Call stack:
  ebuild.sh, line 1546:   Called dyn_compile
  ebuild.sh, line 937:   Called src_compile
  ebuild.sh, line 1255:   Called toolchain_src_compile
  toolchain.eclass, line 24:   Called gcc_src_compile
  toolchain.eclass, line 1527:   Called gcc_do_configure
  toolchain.eclass, line 1327:   Called die

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

This is gcc-config -l

Code: Select all

diamond ~ # gcc-config -l
 [1] i386-pc-linux-gnu-3.3.6 *
 [2] i386-pc-linux-gnu-3.3.6-hardened
 [3] i386-pc-linux-gnu-3.3.6-hardenednopie
 [4] i386-pc-linux-gnu-3.3.6-hardenednopiessp
 [5] i386-pc-linux-gnu-3.3.6-hardenednossp
 [6] i386-pc-linux-gnu-3.4.5
 [7] i386-pc-linux-gnu-3.4.5-hardened
 [8] i386-pc-linux-gnu-3.4.5-hardenednopie
 [9] i386-pc-linux-gnu-3.4.5-hardenednopiessp
 [10] i386-pc-linux-gnu-3.4.5-hardenednossp
 [11] i386-pc-linux-gnu-4.1.1

And this is binutils-config -l

Code: Select all

diamond ~ # binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *

Yes, I've seen that I have big problem here, I can't create any executables. I messed up somewhere in the CHOST settings. Is there a way to get binaries for a working tool chain so I can rebuild?

ziman · Post by **ziman** » Sun Dec 24, 2006 7:42 am

Hey guys, I just joined the forum finally after about 2 years of reading =).

Anyways, I have the same problem as the piggie:

gcc-4.1.1-r1 fails

I just installed from the 2006.1 cd.

after finalizing my system according to the gentoo handbook,

I log in and do emerge -uDN world

but when it gets to emerging gcc-4.1.1-r1

it fails. I have tried re-emerging it but still fails. Should I just not care about this and stick with gcc-4.1.1 ?

lippy · Post by **lippy** » Sun Dec 31, 2006 4:25 pm

I'm having a problem with emerging PHP4. I recently upgraded to GCC 4.1.1 following the gentoo GCC general upgrade instructions. I also moved from PHP4 only via Apache2 module to PHP5 module with PHP4 cgi.

I believe everything was working fine after the Apache/PHP upgrade to module PHP5 with CGI PHP4.

But, after upgrading GCC, everything seemed fine as well. But, I noticed my PHP4 no longer works.

When I run /usr/lib/php4/bin/php-cgi -v
/usr/lib/php4/bin/php-cgi: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

When I try to emerge php4 again, I get:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libsablot.so, not found (try using -rpath or -rpath-link)
/usr/lib/libsablot.so: undefined reference to `operator new(unsigned int)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `__gxx_personality_v0@CXXABI_1.2'
/usr/lib/libsablot.so: undefined reference to `operator delete[](void*)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `__cxa_pure_virtual@CXXABI_1.2'
/usr/lib/libsablot.so: undefined reference to `operator new[](unsigned int)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `operator delete(void*)@GLIBCPP_3.2'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1
make: *** Waiting for unfinished jobs....
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libsablot.so, not found (try using -rpath or -rpath-link)
/usr/lib/libsablot.so: undefined reference to `operator new(unsigned int)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `__gxx_personality_v0@CXXABI_1.2'
/usr/lib/libsablot.so: undefined reference to `operator delete[](void*)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `__cxa_pure_virtual@CXXABI_1.2'
/usr/lib/libsablot.so: undefined reference to `operator new[](unsigned int)@GLIBCPP_3.2'
/usr/lib/libsablot.so: undefined reference to `operator delete(void*)@GLIBCPP_3.2'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

!!! ERROR: dev-lang/php-4.4.4-r6 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_compile
ebuild.sh, line 937: Called src_compile
php-4.4.4-r6.ebuild, line 171: Called src_compile_fastbuild
php-4.4.4-r6.ebuild, line 237: Called php4_4-sapi_src_compile
php4_4-sapi.eclass, line 535: Called die

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

Any help would be appreciated.

GCC 4.1.1 and glibc 2.4 stable on x86 and amd64

can't emerge fluxspace

libstdc++.so.5 problem emerging php4 after updating gcc