[gentoo-amd64] Re: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560710170112u6c8769a9j78eeb474899102d6@××××××××××.com, excerpted
below, on  Wed, 17 Oct 2007 10:12:43 +0200:

> when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this
> error:
>
> ../include/sys/socket.h:21: warning: 'stdcall' attribute ignored
>> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1
>> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not
>> support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error:
>> CPU you selected does not support x86-64 instruction set

Did you ever have the eselect-compiler module, aka gcc-config-2.0, 
installed?  Presumably you've removed it now if you did, but the unmerge 
left some files behind that triggered frustrating errors such as this at 
times.  Let's see if I can find the bug, which has a command that can be 
run to trace down and remove these files (be sure to read my comment on 
the bug, as the initial form of the command as posted caused problems for 
a number of people, removing too much stuff due to bad quoting)...

OK, here we are: http://bugs.gentoo.org/show_bug.cgi?id=133209

Pay particular attention to comments 25,35,39.

That may or may not be your problem, but if it is, it's a fairly easy fix 
for what can be an otherwise extremely frustrating problem.  

FWIW, a few months ago I finally decided to switch to the 64-bit only no-
multilib profile here, since I won't merge binary-only stuff here anyway 
out of principle, and that's mainly why one would need 32-bit 
compatibility as virtually any commonly used freedomware is long since 
ported.  Less problems, and compiling gcc and glibc take MUCH less time 
now, since only the 64-bit stuff has to be compiled, not the 32-bit stuff 
as well.  If I did do 32-bit, I'd now go the 32-bit chroot route, 
installing from a full 32-bit stage-3 thus keeping 32-bit and 64-bit 
separate, instead of fooling with the multilib stuff.  Less problems that 
way, and when there /is/ a problem, it's far more likely to be limited to 
one bitness or the other, not some weird combination of both.  Those dual-
bitness problems aren't common, but they are sure frustrating to try to 
figure out and solve, so eliminating that entire class of problem was at 
least for me a good choice; one I'd have made much earlier if I had it to 
do over again.

-- 
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