1 |
Beso <givemesugarr@×××××.com> posted |
2 |
d257c3560710170112u6c8769a9j78eeb474899102d6@××××××××××.com, excerpted |
3 |
below, on Wed, 17 Oct 2007 10:12:43 +0200: |
4 |
|
5 |
> when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this |
6 |
> error: |
7 |
> |
8 |
> ../include/sys/socket.h:21: warning: 'stdcall' attribute ignored |
9 |
>> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1 |
10 |
>> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1 |
11 |
>> make[2]: *** Waiting for unfinished jobs.... |
12 |
>> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not |
13 |
>> support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error: |
14 |
>> CPU you selected does not support x86-64 instruction set |
15 |
|
16 |
Did you ever have the eselect-compiler module, aka gcc-config-2.0, |
17 |
installed? Presumably you've removed it now if you did, but the unmerge |
18 |
left some files behind that triggered frustrating errors such as this at |
19 |
times. Let's see if I can find the bug, which has a command that can be |
20 |
run to trace down and remove these files (be sure to read my comment on |
21 |
the bug, as the initial form of the command as posted caused problems for |
22 |
a number of people, removing too much stuff due to bad quoting)... |
23 |
|
24 |
OK, here we are: http://bugs.gentoo.org/show_bug.cgi?id=133209 |
25 |
|
26 |
Pay particular attention to comments 25,35,39. |
27 |
|
28 |
That may or may not be your problem, but if it is, it's a fairly easy fix |
29 |
for what can be an otherwise extremely frustrating problem. |
30 |
|
31 |
FWIW, a few months ago I finally decided to switch to the 64-bit only no- |
32 |
multilib profile here, since I won't merge binary-only stuff here anyway |
33 |
out of principle, and that's mainly why one would need 32-bit |
34 |
compatibility as virtually any commonly used freedomware is long since |
35 |
ported. Less problems, and compiling gcc and glibc take MUCH less time |
36 |
now, since only the 64-bit stuff has to be compiled, not the 32-bit stuff |
37 |
as well. If I did do 32-bit, I'd now go the 32-bit chroot route, |
38 |
installing from a full 32-bit stage-3 thus keeping 32-bit and 64-bit |
39 |
separate, instead of fooling with the multilib stuff. Less problems that |
40 |
way, and when there /is/ a problem, it's far more likely to be limited to |
41 |
one bitness or the other, not some weird combination of both. Those dual- |
42 |
bitness problems aren't common, but they are sure frustrating to try to |
43 |
figure out and solve, so eliminating that entire class of problem was at |
44 |
least for me a good choice; one I'd have made much earlier if I had it to |
45 |
do over again. |
46 |
|
47 |
-- |
48 |
Duncan - List replies preferred. No HTML msgs. |
49 |
"Every nonfree program has a lord, a master -- |
50 |
and if you use the program, he is your master." Richard Stallman |
51 |
|
52 |
-- |
53 |
gentoo-amd64@g.o mailing list |