<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr">On Fri, Dec 14, 2012 at 12:24 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">Hello the list,<br>
<br>
At some point in the near future, FreeBSD is going to start transitioning to a new linker (mclinker, which works now, possibly then migrating to lld once it becomes more complete).  People also often install gold or a newer bfd ld from ports.  This means that we will have two, possibly three, linkers in the base system and another two from ports, and yet clang currently hard-codes the fact that the linker is the one called ld that is the first to be found in the path.  I suspect that, initially, mclinker will be adequate for the base system but possibly not for some ports, so we will need to be able to easily select an alternative linker.<br>

<br>
I'd like to add some logic for selecting the linker at run time.  Before I start, I was wondering if anyone had any suggestions as to the correct UI for this.  As far as I can see, there are two possible choices:<br>

<br>
1) We have a flag that takes a full path to the linker to use.  This is somewhat problematic, because if two linkers require different arguments (not much of a problem for us, but imagine on Windows being able to switch between the MS and Binutils linkers) then you need to know what the linker is, as well as its name.<br>

<br>
2) We have a flag like the libc++ / libstdc++ selection flag, which takes an argument like bfd, gold, mc, lld and some logic in the driver to work out what the paths and names of each of these should be.<br>
<br>
Is there a more sensible third option?<br></blockquote><div><br></div><div style>I think the sensible option is for all the linkers on a particular platform to have a compatible commandline interface. Much like Clang has a compatible interface to GCC. This compatibility doesn't have to be perfect (clearly, as Clang's is far from it), but should easily be enough for the small variation of Flags Clang needs to pass.</div>
<div style><br></div><div style>My understanding has been that 'lld' has this as an explicit goal, and certainly bfd and gold both act as a normal 'ld' linker on Linux. I think that if MCLinker wants to be used on a platform where 'ld's flag syntax is the defacto standard, it should be compatible. I think that adding yet another dialect of linker option syntax for such a narrow use case (as you admit it is likely to be only a stop-gap) isn't a lot of complexity for very little gain.</div>
<div style><br></div><div style>I would much rather see the effort go into making 'lld' (or 'MCLinker' for that matter...) be a viable, compatible linker on the particular platform of interest.</div></div>
</div></div></div>