Re: [PATCH] PR binutils/14625: Enable 64-bit archives in ar and ranlib

[Alan Modra <amodra at gmail dot com>]

On Fri, May 20, 2016 at 05:10:02AM -0700, H.J. Lu wrote:
> Since existing ld and gold support the 64-bit (MIPS) ELF archives, we
> can use the 64-bit (MIPS) ELF archives as 64-bit archives.  Since the
> plugin target is used to create archive in plugin-enabled ar, we need
> a way to enable 64-bit archives in the plugin target.  This patch adds
> --enable-64-bit-archive to bfd to enable 64-bit archives in ar and
> ranlib.  Since both 64-bit MIPS and s390 ELF targets currently use
> 64-bit archives, all Linux linkers with 64-bit BFD support both 32-bit
> and 64-bit archives, 64-bit archives are enabled by default for them.

Hmm, isn't it true that archive64.c is compiled in for any 64-bit
target?  I also don't see anything ELF specific in archive64.c.

> +  # Since all Linux linkers support both 32-bit and 64-bit archives,
> +  # it is safe to enable 64-bit archives for Linux targets with 64-bit
> +  # bfd_vma.
> +  case "${target}${want64}" in
> +    *linux*true)
> +      want_64_bit_archive=true
> +      ;;
> +  esac
> +fi

So the above could just set want_64_bit_archive based on want64,
ignoring target, except that doing so might result in archives that
aren't recognized by native tools.  How about instead of this
configure option, changing _bfd_compute_and_write_armap to choose the
archive64.c write_armap whenever the archive size is larger than 2G?
I think that might just work automatically.

The rest of the patch looks reasonable except that you missed changing
elf64-ia64-vms.c, and I think the libbfd-in.h defines would be better
with the coff defines substituted.  eg. _bfd_slurp_extended_name_table
rather than _bfd_archive_coff_slurp_extended_name_table.

-- 
Alan Modra
Australia Development Lab, IBM