Attaching build log and emerge --info output. Reproducible: Always Steps to Reproduce:
Created attachment 207838 [details] Build log
Created attachment 207840 [details] Emerge info
First, just to make sure: was emerge started from a shell started after you've selected 4.4.2 (just making sure it's not simply stale environment) ? If so, then perhaps fixing libtool files has failed and you need to manually run that.
(In reply to comment #3) > First, just to make sure: > was emerge started from a shell started after > you've selected 4.4.2 (just making sure it's not > simply stale environment) ? > > If so, then perhaps fixing libtool files has failed > and you need to manually run that. Nope and nope. Been using gcc 4.4.2 since the ebuild hit main tree.
Does reemering libtool help ? See 'gcc --version' and content of /etc/ld.so.conf to make sure. Also there were problems with '-O3' and gcc 4.4.1, perhaps problem lies there ?
Interestingly, something left behind /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4/gnu/awt/j2d/(In reply to comment #5) > Does reemering libtool help ? > See 'gcc --version' and content of /etc/ld.so.conf to make sure. > Also there were problems with '-O3' and gcc 4.4.1, > perhaps problem lies there ? No problems there. Re-emerging libtool did the trick. The question is: why? Does something need to be changed in the gcc ebuild to diddle libtool to alert it to the new version? Also, when is libemf's code going to be cleaned up to remove the raft of warnings? :D And, unrelatedly, why was /etc/env.d/20java still chock-full of references to Sun JDK 1.4.2.19, a couple years after I upgraded to 1.6.0.x and months and months after I completely removed 1.4.2.19? :D
So, this is no libemf problem - closing. Your other questions would be something for IRC or separate bugs, then.
