Re: 2.18 ar/ranlib glitch for mips elf64

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Paul Koning" <Paul_Koning@Dell.com> writes:
>> > > In trying to build a toolchain that can handle MIPS N64, I ran
> into
>> > an
>> > > issue for that case.  I built a pile of object files (those are
>> > > elf64-tradlittlemips BFD format).  Built an archive with "ar cq"
>> and
>> > > 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
> build
>> > > process creates.  Readelf tells me that every member in the
> archive
>> > is
>> > > elf64, so I have no idea where those ecoff things come from.  I
> see
>> > 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.

Richard