dependency list for static libraries

[Nick Clifton]

Hi Howard,

> Here's a proposed patch to ar to implement the first half of the solution:
> storing the dependencies into a static library.

Some comments on the patch:

  * You need to add documentation of the new feature to binutils/doc/bin.texi
    and also a note to binutils/NEWS.

  * Whilst single letter options are the convention for ar, it would also be
    good if the GNU convention of providing a more verbose alternative option
    name were used to.  Eg --record-libdeps=<string>.

    Whilst on the subject of options, you should add some error checking for
    the presence of multiple L options.

  * There are several places where you call bfd library functions but do not
    check the return values.  This is a bad idea.  Always be paranoid and
    check to ensure that a function call has succeeded.

  * It is not clear to me why you create a binary bfd for Libdeps_bfd but
    then convert it to a plugin type bfd.  Can you explain what you are
    doing here ?

  * The change to the code to call ar_emul_replace() inside replace_members()
    looks wrong to me.  The current code will try to replace all of the entries
    on the files_to_move list, and will set changed to TRUE if any of the
    replacements succeeds.  The patched code will changed to FALSE if any
    replacement fails, even if earlier ones succeeded.  Plus once one 
    replacement has failed, future successful replacements will not be removed 
    from the archive chain.

  * There are some formatting issues as well. These are minor, but it is 
    helpful to ensure that the codebase uses a uniform style.  Please check
    out the GNU Coding Standards for more information:

      https://www.gnu.org/prep/standards/standards.html

   * It would also be really helpful if you could create a test for the
     binutils testsuite that checks this new functionality.


> It looks like I may be able
> to use the linker plugin facility to handle the ld side of things. But it's
> not clear to me that it won't clash with other plugins. I.e., if one plugin
> claims an archive file, will that prevent other plugins from being able to
> process it?

I am not sure that this has been done before, but I think that you are right -
once a file/archive has been claimed by one plugin, it cannot be claimed by
another.  It may however be possible for your plugin to process an archive
but not claim it.  This is just an idea - I have not tested it - and it might
mean that the ordering of plugins on the command line becomes important...

Cheers
  Nick