[cfe-dev] Linker selection

[Chandler Carruth]

On Fri, Dec 14, 2012 at 12:24 AM, David Chisnall <
David.Chisnall at cl.cam.ac.uk> wrote:

> Hello the list,
>
> 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.
>
> 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:
>
> 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.
>
> 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.
>
> Is there a more sensible third option?
>

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121214/4654c5c7/attachment.html>