1 |
"Avuton Olrich" <avuton@×××××.com> posted |
2 |
3aa654a40710170543g6d32654bufdece91de9454e05@××××××××××.com, excerpted |
3 |
below, on Wed, 17 Oct 2007 05:43:17 -0700: |
4 |
|
5 |
> Strange thing happened the other day when I went to emerge |
6 |
> media-sound/musepack-tools, got the following: |
7 |
> |
8 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/ |
9 |
bin/ld: |
10 |
> i386 architecture of |
11 |
> input file `cpu_feat.o' is incompatible with i386:x86-64 output |
12 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/ |
13 |
bin/ld: |
14 |
> i386 architecture of |
15 |
> input file `synthasm.o' is incompatible with i386:x86-64 output |
16 |
> |
17 |
> Is this a bug, or no? Any idea what causes it? |
18 |
|
19 |
ld is the linker. For some reason, those *.o files (native binary object |
20 |
files linked together to form libraries or executables) are 32-bit, while |
21 |
the invoked linker is 64-bit. The two bitnesses cannot be mixed in the |
22 |
same executable or shared object library (*.so*), thus the protest. |
23 |
(FWIW, there's a separate 32-bit linker for x86 code.) |
24 |
|
25 |
As musepack-tools isn't masked for 64-bit and according to esearch is |
26 |
lgpl-2.1 licensed, one wouldn't expect it to have any 32-bit-binary-only |
27 |
code lurking around, so the problem must be a mixup in your compiler |
28 |
wrappers. I'm betting it's the old gcc-config-2.0 aka eselect-compiler |
29 |
module wrappers rearing their head once again. See the glibc-2.6.1 cpu |
30 |
error thread for another current discussion of it, and the following bug |
31 |
for a fix. |
32 |
|
33 |
I should caution reading the bug thru may be wise, particularly comments |
34 |
25,35, and 39, or at least 39. The reason being the command suggested in |
35 |
comment 25 has been problematic for many, removing way to much stuff. |
36 |
The command I suggest in 39 worked far better here, and eliminating the |
37 |
files it listed solved the issue for me. As I suggested in the other |
38 |
thread, if it lists files you are in doubt about, simply move/rename them |
39 |
temporarily. That way you can move/rename them back if necessary, but |
40 |
I'm pretty confident it shouldn't be necessary and they should be safe to |
41 |
remove. (Of course, so was the guy in comment 25, so...) |
42 |
|
43 |
http://bugs.gentoo.org/show_bug.cgi?id=133209 |
44 |
|
45 |
This assumes of course that you didn't simply create your own gcc- |
46 |
config-2.0 package when the old one was removed, and aren't continuing to |
47 |
use it, as I did for awhile, until I decided it was too much trouble for |
48 |
the benefit involved. |
49 |
|
50 |
-- |
51 |
Duncan - List replies preferred. No HTML msgs. |
52 |
"Every nonfree program has a lord, a master -- |
53 |
and if you use the program, he is your master." Richard Stallman |
54 |
|
55 |
-- |
56 |
gentoo-amd64@g.o mailing list |