[gentoo-amd64] incompatible with i386:x86-64 output

[gentoo-amd64] incompatible with i386:x86-64 output

[Avuton Olrich]

Hello,

Strange thing happened the other day when I went to emerge
media-sound/musepack-tools, got the following:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/bin/ld:
i386 architecture of
 input file `cpu_feat.o' is incompatible with i386:x86-64 output
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/bin/ld:
i386 architecture of
 input file `synthasm.o' is incompatible with i386:x86-64 output

Is this a bug, or no? Any idea what causes it?

Thanks,
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: incompatible with i386:x86-64 output

[Duncan]

"Avuton Olrich" <avuton@gmail.com> posted
3aa654a40710170543g6d32654bufdece91de9454e05@mail.gmail.com, excerpted
below, on  Wed, 17 Oct 2007 05:43:17 -0700:

> Strange thing happened the other day when I went to emerge
> media-sound/musepack-tools, got the following:
> 
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/
bin/ld:
> i386 architecture of
>  input file `cpu_feat.o' is incompatible with i386:x86-64 output
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/
bin/ld:
> i386 architecture of
>  input file `synthasm.o' is incompatible with i386:x86-64 output
> 
> Is this a bug, or no? Any idea what causes it?

ld is the linker.  For some reason, those *.o files (native binary object 
files linked together to form libraries or executables) are 32-bit, while 
the invoked linker is 64-bit.  The two bitnesses cannot be mixed in the 
same executable or shared object library (*.so*), thus the protest.  
(FWIW, there's a separate 32-bit linker for x86 code.)

As musepack-tools isn't masked for 64-bit and according to esearch is 
lgpl-2.1 licensed, one wouldn't expect it to have any 32-bit-binary-only 
code lurking around, so the problem must be a mixup in your compiler 
wrappers.  I'm betting it's the old gcc-config-2.0 aka eselect-compiler 
module wrappers rearing their head once again.  See the glibc-2.6.1 cpu 
error thread for another current discussion of it, and the following bug 
for a fix.

I should caution reading the bug thru may be wise, particularly comments 
25,35, and 39, or at least 39.  The reason being the command suggested in 
comment 25 has been problematic for many, removing way to much stuff.  
The command I suggest in 39 worked far better here, and eliminating the 
files it listed solved the issue for me.  As I suggested in the other 
thread, if it lists files you are in doubt about, simply move/rename them 
temporarily.  That way you can move/rename them back if necessary, but 
I'm pretty confident it shouldn't be necessary and they should be safe to 
remove.  (Of course, so was the guy in comment 25, so...)

http://bugs.gentoo.org/show_bug.cgi?id=133209

This assumes of course that you didn't simply create your own gcc-
config-2.0 package when the old one was removed, and aren't continuing to 
use it, as I did for awhile, until I decided it was too much trouble for 
the benefit involved.

-- 
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@gentoo.org mailing list