ar (and ranlib) do not correctly identify ELF64 files in an archive. It complains that the format is ambiguous. See the testcase below: [tesla:~]$ touch foo.c [tesla:~]$ gcc -mabi=64 -o foo.o -c foo.c [tesla:~]$ ar cq libfoo.a foo.o [tesla:~]$ ar t libfoo.a ar: libfoo.a: File format is ambiguous ar: Matching formats: ecoff-littlemips ecoff-bigmips elf64-tradlittlemips [tesla:~]$
Is this still the case with current binutils? A 2007-09-14 patch may have fixed this problem.
Not a bug. If you don't configure binutils with support for a particular target, ar won't recognize those object files. mipsel-linux doesn't support 64-bit mips by default. Use --enable-targets to add more targets.
The binutils on which the problem exists is already built with "--enable-targets=mips64el-linux-gnu". It is confirmed by the error message: ar: Matching formats: ecoff-littlemips ecoff-bigmips elf64-tradlittlemips What should be the correct --enable-targets for 64-bit mipsel?
Can you try the current CVS?
I am not able to reproduce the problem anymore with the latest CVS. I guess the problem has been fixed recently, but I don't know exactly when. Thanks for the fix.
I can reproduce the problem with current CVS, and since I closed it incorrectly at comment #2, I'm reopening.
Created attachment 2206 [details] potential fix ar tries to open the archive for all supported bfd targets. Normally, bfd checks that the first object in an archive is the same target as the archive to count as a successful match, but it doesn't do this if the archive has no armap. When one of more of the ecoff targets is supported, the ecoff archive check decides there is no armap (correctly, since there is no ecoff armap), so the ecoff target is incorrectly taken to match.
http://sourceware.org/ml/binutils-cvs/2008-01/msg00109.html http://sourceware.org/ml/binutils/2008-01/msg00222.html
Thanks a lot for the fix. I have just tested and it works fine for me.