I'll outline what I did, then give a sort of timeline: Around Jun 9 I upgraded my gcc to the new 3.3 masked in portage. I proceded to upgrade a few more things. Early on the 10th, I upgraded my gtk+ to gtk+-2.2.2, and installed evolution and friends, and some other stuff. I notices garbled icons, and tried re-compiling a lot of stuff to no avail. I then downgraded gcc, then recompiled a bunch of stuff. This is when I noticed many programs complaining about FILE and stderr (<sdtio.h> stuff) being missing. Specifically, a good example is gnome-extra/at-spi-1.3.2-r1 from breakmygentoo.net. This package compiled fine before the compiler downgrade. I will attach the log of this particular failure. I have re-emerged linux-headers, baselayout, glibc, gcc-3.3, and every other thing I could think of. Nothing has worked. The crux of the issue is that a .c file did not need to explicitly #include <sdtio.h> before my compiler downgrade. I suspect that some internal include now has "#include <stdio.h>" missing. Can someone help me pin down what happened? Maybe someone with a working system can: 1. compile that file manually using "strace -f", finding all ".h" files 2. egrep those ".h" files for "#include .*stdio.h" or something ? Reproducible: Always Steps to Reproduce: 1. Upgrade to gcc-3.3 2. Downgrade to gcc-3.2.3-r1 3. Try to compile gnome-extra/at-spi-1.3.2-r1 from breakmygentoo.net Actual Results: http://www.enodev.com/at-spi-compile-fail.txt (or the full one) http://www.enodev.com/at-spi-compile-fail-full.txt Expected Results: stdio.h should have been pulled in somehow, as it had been before. I suspect that some internal include now has "#include <stdio.h>" missing.
By the way, the garbled graphics problem turned out to be a bug with the experimental RenderAccell extention in nvidia's driver. I turned it off in X's config and it went away.
I wonder if there was something from the stage tarball that got clobbered for the first time?
On that note, I'm installing a mini-chroot Gentoo in /alt and I'm going to try to do exactly that which I've suggested, in order to gleen more info. Will report progress...
You've certainly had a bit of an uphill battle :) I will try and look into this issue sometime in the next week, good luck on finding the solution! I will be eager to hear of your reports.
Hi guys, the bug was with ORBit2 between 2.7.1 and 2.7.2. /usr/include/orbit-2.0/orbit/GIOP/giop-recv-buffer.h includes <stdio.h>, and in fact, that's where those defines get pulled in from when compiling this failing stuff. /usr/include/orbit-2.0/orbit/GIOP isn't even there in ORBit2-2.7.2-r1. So, maybe a big reorg in ORBit2 includes busticated all my thingamabobs. So, when you guys get going on your unstable gnome builds for portage, this ought to be sorted out. See, breakmygentoo just motivates folks to fix breakage by breaking-my-gentoo. It's a good thing! #include <std_disclaimer.h>
From http://forums.gentoo.org/viewtopic.php?p=365396&highlight=#365396 I should have noted that /usr/include/orbit-2.0/orbit/GIOP does not even exist on ORBit2-2.7.2-r1 from breakmy. Big include reorg in ORBit2 maybe? (In a N.N.[x+1] revision release, no doubt!!!) The first major difference in the critical path to including stdio.h is -/usr/include/orbit-2.0/orbit/orb-core/orb-core.h +/usr/include/orbit-2.0/orbit/GIOP/giop.h where now in 2.7.2 <orb-core/orb-core.h> gets included instead of <GIOP/giop.h> due to the #ifdef ORBIT2_INTERNAL_API # include <orbit/GIOP/giop.h> #endif in <orbit/orbit.h> I just shot the gnome on my lawn with a ten gauge ;)
with this being a breakmygentoo release, and after talks with gnome team it has been decided that we cannot address this issue. it will be visited whtn the time coems with gnome 2.4, although for now, 2.3 breakages cannot be catered for. I would like to thankyou for the early warning however :D - John
assuming invalid if this is still occuring please tag a note onto the bug
