<div dir="ltr">On Fri, Sep 20, 2013 at 5:08 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Sep 20, 2013 at 04:39:04PM -0700, Rui Ueyama wrote:<br>
> I don't want to make Resolver to have a reference to input graph. The point<br>
> of this proposal is to separate input graph handling from Resolver and<br>
> instead making Linker Context to do that task.<br>
<br>
</div>That was the part of the original proposal I didn't agree with and I<br>
still don't do. While the resolver shouldn't have to deal with the<br>
details of the command line, it certainly should know about the input<br>
graph. I wouldn't be surprised if it can make a significant difference<br>
for group processing whether a DFS or BFS is applied, even if the result<br>
doesn't change. There are other concerns like the recursive processing<br>
of DT_NEEDED for ELF and the resulting implications for symbol<br>
resolution and locking.</blockquote><div><br></div><div>Someone should certainly know about the input graph, but it isn't necessarily be Resolver. In my proposal Linking Context gets update for each step of linking from Resolver and makes a decision based on that. I don't see why you think the search order would change in this model. I think it shouldn't change.</div>

<div><br></div><div>I don't also understand if DT_NEEDED is related to this. DT_NEEDED is not represented by input graph. And what is <i>recursive</i> processing of DT_NEEDED?</div></div></div></div>