2.18 ar/ranlib glitch for mips elf64
Sat Jun 5 06:44:00 GMT 2010
"Paul Koning" <Paul_Koning@Dell.com> writes:
>> > > In trying to build a toolchain that can handle MIPS N64, I ran
>> > an
>> > > issue for that case. I built a pile of object files (those are
>> > > elf64-tradlittlemips BFD format). Built an archive with "ar cq"
>> > > that worked. But then attempts to look at that archive with ar or
>> > > ranlib fail with "File format is ambiguous" and "matching formats:
>> > > elf64-tradlittlemips ecoff-littlemips ecoff-bigmips".
>> > >
>> > > I noticed the same issue applies to the libgcc.a that the GCC
>> > > process creates. Readelf tells me that every member in the
>> > is
>> > > elf64, so I have no idea where those ecoff things come from. I
>> > no
>> > > way to tell ar what the actual format is.
>> > >
>> > > Should I use a newer binutils? Should I yank ecoff support out?
>> > (That
>> > > certainly wouldn't bother me...)
>> > Try the latest released version.
>> That fixes it.
> Well, yes and no.
> It cures this particular problem, but replaces it by several others.
> I'm trying to build a libc, which involves creating a pile of object
> libraries, putting them into an archive (that step now works) and then
> feeding that archive to the linker with a whole-archive switch.
> That step is blowing up. The way it blows up depends on whether I fed
> the archive to ranlib.
> If ranlib is NOT used, I see hundreds of assert failures in
> bfd/elfxx-mips.c:3134, which seems to be a check on a GOT index. (I
> don't know what that means or how to debug it.)
> If ranlib IS used, then the link fails with "member libc_pic.a() is not
> an object". That prompted me to do "ar -t" on the archive. I noticed
> that it has some blank lines in the output, which is very strange.
> Those blank lines also show up in the n64 version of libgcc.a, but not
> in the n32 version.
> Something that's probably unrelated but I'll mention it just in case:
> "readelf" applies to the archive after ranlib has been done on it fails
> with a segmentation fault (and no other output). It works fine on the
> archive prior to ranlib.
Best thing to do is file a bug report with specimen objects and archives.
There isn't really enough information here to tell what's going wrong.
FWIW, I was able to build n64 GLIBCs without problems in the past
(and did it regularly for a time). Obviously others have too.
So it sounds like your problems might be specific to particular
features of the object files, rather than an ar-and-ranlib-just-
can't-handle-n64 level of problem.
More information about the Binutils