[gentoo-amd64] Re: About gcc 4.1.1

[Duncan]

Richard Freeman <rich@××××××××××××××.net> posted
44F88FD3.2020809@××××××××××××××.net, 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

-- 
gentoo-amd64@g.o mailing list