RE: 2.18 ar/ranlib glitch for mips elf64

["Paul Koning" <Paul_Koning at Dell dot com>]

> > > 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.

I think I'm going to try Plan B...

	paul