2.18 ar/ranlib glitch for mips elf64

2.18 ar/ranlib glitch for mips elf64

[Paul Koning]

Gents,

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

	paul

Re: 2.18 ar/ranlib glitch for mips elf64

[David Daney]

On 06/04/2010 10:57 AM, Paul Koning wrote:
> Gents,
>
> 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.

Also which "ar" are you referring to above?  Is it the system ar or the 
ar you just built?  If you are in a cross environment, I don't think you 
can use the system ar.

David Daney

RE: 2.18 ar/ranlib glitch for mips elf64

[Paul Koning]

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

Trying that now.

> Also which "ar" are you referring to above?  Is it the system ar or
the
> ar you just built?  If you are in a cross environment, I don't think
> you
> can use the system ar.

Sorry, I was using shorthand.  I meant the ar and ranlib that were built
in the cross build process.

	paul

RE: 2.18 ar/ranlib glitch for mips elf64

[Paul Koning]

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

	paul

RE: 2.18 ar/ranlib glitch for mips elf64

[Paul Koning]

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

Re: 2.18 ar/ranlib glitch for mips elf64

[Richard Sandiford]

"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

RE: 2.18 ar/ranlib glitch for mips elf64

[Paul Koning]

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

Ok, I'll try to isolate the problem.  The library being built in this
case is newlib (on NetBSD).  Also, does the gcc version matter?  I would
hope not since gcc doesn't deal in binaries, but in any case, it's
3.3.3.

	paul