dependency list for static libraries

[Nick Clifton]

Hi Howard,

>>   * 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 ?
> 
> This was a major hassle, I should have commented it. The bfd gets created
> with type "plugin", and that refuses the bfd_bwrite() call. (Just fails.)
> The write only succeeded if I set it to "binary" type first. But then, trying
> to add this bfd to the archive failed unless I changed the type back to "plugin."

OK - please could you add a comment to this effect to enlighten future readers.


> All of this was unexpected, none of the docs for make_writable or make_readable
> mentioned anything about these incompatibilities.

Yes, the "plugin" architecture type is special.  It is not meant to be an ordinary 
bfd type.  And of course you are right - the binutils internal documentation is 
woeful to say the least.

 
>>   * 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.
> 
> No, that's not correct. The patched code ORs in the result, so it will not
> change any previous success into a failure.

Doh - OK, I misread this.  But I think that there is still a possible problem.  
Since the result is ORed in, if there is a failed call to ar_emul_replace after 
a successful one, changed will still be TRUE, and the failed element will be 
removed from the chain.  This differs from the old behaviour where the element
would not be removed if ar_emul_replace() fails.  (I am not sure however what
the impact of this change will be).


> OK. Any suggestions on what exactly to check?

Sure.  I would suggest adding a test that checks to see that:

 ar cvL libfoo.a "/foo/bar/" foo.o

(something like that) actually creates a library with a libdeps element
in it.  Take a look at binutils/testsuite/binutils-all/ar.exp where other
tests on ar are run.  Basically you need to create a new proc to the file
and then invoke it at the end of the file.  The new proc would probably
look something like this:

proc test_add_dependencies { } {
    global AR
    global AS
    global srcdir
    global subdir
    global obj

    set testname "ar adding library dependencies"

    if ![binutils_assemble $srcdir/$subdir/bintest.s tmpdir/bintest.${obj}] {
	unresolved $testname
	return
    }

    if [is_remote host] {
	set archive artest.a
	set objfile [remote_download host tmpdir/bintest.${obj}]
	remote_file host delete $archive
    } else {
	set archive tmpdir/artest.a
	set objfile tmpdir/bintest.${obj}
    }

    remote_file build delete tmpdir/artest.a

    set got [binutils_run $AR "-r -c $archive --record-libdeps /foo/bar ${objfile}"]
    if ![string match "" $got] {
	fail $testname
	return
    }

    set got [binutils_run $AR "-t $archive ${objfile}"]
    set expected_output "${objfile}^M__,LIBDEP"
    if ![string match $expected_output $got] {
	fail $testname
	return
    }

    pass $testname
}


Cheers
  Nick