Re: [PATCH] dependency list for static libraries

[Fangrui Song <i@maskray.me>]

Did the thread start at
https://sourceware.org/legacy-ml/binutils/2017-09/msg00158.html ?

If all dependencies are specified on the command line but there are
"backward references", we can step back and think about loosing the
requirement like some other binary formats:
https://sourceware.org/pipermail/binutils/2020-September/113194.html "Memoryless" archive processing of ld

If some archives want system libraries (e.g. -lm -lpthread), MSVC style
#pragma comment(lib, "pthread")
may be convenient. clang supports the syntax for ELF and the syntax has
been used in several places in libc++. LLD supports .deplibs (
http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html
http://llvm.1065342.n5.nabble.com/llvm-dev-RFC-ELF-Autolinking-td126998.html )

On 2020-09-22, Howard Chu wrote:
>Nick Clifton wrote:
>> 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.
>
>OK, new patch attached. Added comments, NEWS entry, texi doc, test case.
>
>>>>   * 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, fixed this to preserve the original behavior for failed elements.
>
>>> 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:
>
>Thanks. Had to tweak 2 lines but otherwise this worked.
>
>> proc test_add_dependencies { } {