<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr">On Fri, Dec 14, 2012 at 3:50 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" class="cremed">David.Chisnall@cl.cam.ac.uk</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 14 Dec 2012, at 11:10, Erik Cederstrand wrote:<br>

<br>
> What we really need is a more flexible way of specifying which linker the compiler should use internally. Replacing /usr/bin/ld with a symlink is not flexible.<br>
<br>
</div>In particular, we anticipate a fairly long tail of third-party ports that require GNU ld, just as we have a tail that requires libstdc++ and won't work with libc++.  The base system will be using libc++ and hopefully will be using mclinker, and so will most ports, but we still don't even have 100% of ports working with clang yet...<br>

<br>
As Chandler says, this is a short-term requirement, but short-term in this context means (optimistically) 'the next 3-5 years'.</blockquote><div><br></div><div style>Note that my point was only that we shouldn't need a custom set of command line flags for mclinker, and we shouldn't need to switch command line flags when switching linkers while staying on the same target platform. Thus, we might consider simple solutions that only address the problem of switching the link binary used rather than a more complex solution which passes flags in a new dialect.</div>
<div style><br></div><div style>Also, my "short-term requirement" was using mclinker as opposed to lld -- I completely agree that the bfd linker will likely be kicking around and in use for a long time in a few oddball scenarios.</div>
</div></div></div></div>