2.15 problem building GCC arm-elf cross-compiler on Solaris/HP-UX

[Albert Chin]

On Wed, Sep 29, 2004 at 06:53:33PM +0100, Nick Clifton wrote:
> >I've built a GCC cross-compiler for C with --target=arm-elf
> >successfully on RH 7.1, 9.0, and Solaris 9/SPARC. However, when
> >building on HP-UX 11i, I get an error running arm-elf-ranlib on
> >libgcc.a:
> >  ...
> >  arm-elf-ar  rc ./libgcc.a libgcc/./_udivsi3.o libgcc/./_divsi3.o ...
> >  arm-elf-ranlib ./libgcc.a
> >  arm-elf-ranlib: ./libgcc.a: File format not recognized
> >
> >binutils-2.12.1 works on HP-UX 11i.
> >
> 
> >  $ diff -u /tmp/binut212 /tmp/binut215
> >  --- /tmp/binut212    2004-09-29 10:03:55.000000000 -0500
> >  +++ /tmp/binut215    2004-09-29 10:04:04.000000000 -0500
> >  @@ -1,16221 +1,16221 @@
> >  -0000000 213c 6172 6368 3e0a 2f20 2020 2020 2020
> >  -0000020 2020 2020 2020 2020 3130 3936 3437 3032
> 
> >  +0000000 2f20 2020 2020 2020 2020 2020 2020 2020
> >  +0000020 3130 3936 3437 3032 3636 2020 3020 2020
> 
> >Any ideas?
> 
> It would appear that the 2.15 libgcc.a is missing the magic bytes 
> "!<arch>\012" at the start of the file.  These bytes are defined as 
> ARMAG in include/aout/ar.h and should be emitted by the function 
> _bfd_write_archive_contents() in bfd/archive.c.  For some reason this is 
> not happening.  Perhaps you could investigate further ?

I did some investigation. The "!<arch>\012" header is written twice.
The second time, we fall into (line 1672):
  if (makemap && hasobjects)
    {
      if (! _bfd_compute_and_write_armap (arch, (unsigned int) elength))
        return FALSE;
    }

In _bfd_compute_and_write_armap(), we fall into (line 1797):
  /* Map over each element.  */
  for (current = arch->archive_head;
       current != NULL;
       current = current->next, elt_no++)
    {

At this point, the arch->where member is 8. After this loop completes,
the arch->where member is 0, forcing new data written to the output
file to be written at offset 0, not 8, thereby overwriting
"!<arch>\012". I traced through the loop and, at the final iteration
of the loop, before current != NULL, a call is made to (line 1802):
      if (bfd_check_format (current, bfd_object)
          && (bfd_get_file_flags (current) & HAS_SYMS) != 0)
        {

The call to bfd_check_format (current, bfd_object) resets arch->member
to 0. I don't know why yet. Does this help anyone?

-- 
albert chin (china@thewrittenword.com)