Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 01 Sep 2006 15:53:55 -0400:
> Duncan wrote: >> >> Quoting the gist of the general instructions: >> >> Code Listing 2.1: Upgrading GCC >> # emerge -uav gcc >> > > > Ok, that is failing for me after a long time (probably on the second pass): > > > checking for x86_64-pc-linux-gnu-gcc... > /var/tmp/portage/gcc-4.1.1/work/build/./gcc/xgcc -B/var/tmp/po > rtage/gcc-4.1.1/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ > - -B/usr/x86_64-pc-linux-gnu/lib/ -isystem > /usr/x86_64-pc-linux-gnu/include -isystem > /usr/x86_64-pc-linux-gnu/sys-include -m32 > checking for C compiler default output file name... a.out > checking whether the C compiler works... > configure: error: cannot run C compiled programs. > Not sure what is going on here. That -m32 doesn't look good though (but > what do I know?). > > I am able to compile both 64-bit and 32-bit in general (tested simple > shell of a .c file). And it compiled for a long time before dieing. Last time that happened here, it was due to some crap left over from an unclean upgrade. (I had a partial hard drive failure and in recovering from that using backups, my portage database in /var/db got out of sync with what I really had merged on the rest of my system. I remerged all the new packages to get everything back in sync, but that left a lot of orphaned old files around.) It was seeing an old copy of some things and therefore getting screwed up. After I devised a script that matched up the files that portage said belonged to packages (using equery files or equery belongs) with the files actually on the disk, and listed any that didn't belong to anything, then manually removed most of those files (a few were there for a reason), the problem disappeared. If you aren't handy enough with bash or other scripting to devise such a script, you can do it manually, but it'll take awhile. I'd start with an equery files for glibc and gcc, comparing the actual files you have on-disk including version with what portage says you should have, paying special attention where you have two versions of a file. If you find a few orphaned files there, that may fix the problem and you won't have to go further (except that you should do so eventually anyway, as those old stale versions will continue to cause problems for some time, and may be security vulnerabilities if they get used instead of the newer and presumably patched versions). Alternatively, you may be able to work with someone who knows a quite a lot more than I do about gcc and/or glibc, and be able to find the problem. For a start, after the broken compile, you should have a config.log file in the build dir, that will tell you what lines of the configure script actually went wrong and how, and you (or someone else who knows about it) can work from there at discovering the problem. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
