Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
