<div dir="ltr">I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic libraries (or regular object files) only once even if they are in --{start,end}-group.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 11:03 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<br>
--start-group/--end-group functionality with the Gnu flavor currently works only if the --start-group/--end-group contains archive files.<br>
<br>
If they contain dynamic libraries, the undefined atoms from the dynamic libraries are processed whenever the group is iterated again.<br>
<br>
I am trying to find out a way to make the resolver add undefined atoms from the shared library only *once*, when the SharedLibrary is first visited as part of the Group.<br>
<br>
The only approach that I can think of is having a std::map in the resolver and using that to process undefined atoms from shared libraries the first time the shared library is visited. I dont like this approach as its not clean.<br>


<br>
Any alternative approaches to handle this ?<br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</font></span></blockquote></div><br></div>