Every time I try to emerge xfree-4.3.0-r3 or r2, the ebuild fails at the install stage. I went tinto the xc directory, and tried to install manually, but I get the same faliure that way as well.
Created attachment 14937 [details] Install log.
My system has plenty of hard disk space, so that is not an issue. I am using the 3dfx USE flag, and -03 -march athlon-xp compiler flags. X builds just fine.
ran out of diskspace
The hard disk partition where I was trying to build and install X had 97 Gigs. of free storage. I also had 480 megs of free RAM and 3 Gigs of free swap. The only way I found to resolve this issue is to emerge -e xfree, which is not really an elegant solution.
Which filesystem?
Reiser. That's what you're asking?
I was having this exact same problem a couple weeks ago when trying to upgrade to xfree-4.3.0-r3. It was because of a build error way in the begining of compilation due to bad permissions on /usr/bin/{cc,cpp}, and it didn't show up until the src_install of the ebuild. I traced the error down to an incorrect gcc-config installation error where having a umask 077 in /etc/profile caused /usr/bin/{cc,cpp,gcc,g++,c++,etc} to be installed -rwx------ That might explain why emerge --emptytree xfree fixed the problem for Dmitri (reinstalled gcc-config), though that approach didn't work for me. I had to change back to gentoo default umask 022 in /etc/profile, and reinstall gcc-config. Then emerge xfree worked fine. Maybe I should file a bug about that. Maybe if Dmitri still had the full build log of the original failure he could check for a bunch of "permission denied" errors in it.
Is this reproduceable?
I can reproduce it as follows: 1) have voodoo3/3dfx/etc. set in USE flags 2) substitute all occurences of "umask XXX" in /etc/profile with "umask 077" 3) emerge gcc-config (after this permissions are -rwx------ on /usr/bin/{gcc,cpp,cc,etc.) 4) emerge xfree Attaching begining and end portions of resulting xfree build log.
Created attachment 20744 [details] xfree-4.3.0-r3 build log of reproduced bug
OK, so the problem is that gcc-config doesn't check for bad permissions. Correct?
Yeah the gcc-config ebuild should probably be fixed to make sure permissions are setup correctly upon installation. Didn't get fixed in bug 19395
After reading that discussion, I'm gonna mark this duplicate. You can continue arguing for the change there if you wish. *** This bug has been marked as a duplicate of 19395 ***
Sorry, I re-read that bug and I think it involves a different issue. The reporter of that bug was saying that gcc-config should override the users umask when being run manually from the command-line. But when gcc-config runs from the gcc-config ebuild it should probably being manually setting the correct permissions. Should I file a new bug?
I think the issue's close enough that is a good place for talking about it.
