[cfe-dev] Adding -fuse-ld= support to clang

Greg Fitzgerald garious at gmail.com
Thu Jan 23 15:28:30 PST 2014

Did this patch make it in?  Doesn't look like it.  What happened?


On Sun, May 19, 2013 at 6:07 AM, David Chisnall
<David.Chisnall at cl.cam.ac.uk> wrote:
> On 19 May 2013, at 08:19, Dimitry Andric <dimitry at andric.com> wrote:
>> Note, gcc does not look for ld-gold or ld-bfd, only for ld.gold and ld.bfd.
> I'm happy to remove this part.  GNU binutils (at least, from the FreeBSD port) used to install gold as ld-new, and I wanted to support that, but it may be that it's a legacy thing that we don't care about.
> On 19 May 2013, at 01:14, "C. Bergström" <cbergstrom at pathscale.com> wrote:
>> Fencepost comment, but does it ever make sense to respect LD in env?
> I pondered this.  Solaris has some crazy logic that causes ld to exec a different ld if it's set.  I'm hesitant to propose (more) environment variables that alter the compile semantics, because they make debugging problem reports very hard.
> On 19 May 2013, at 01:02, Justin Bogner <mail at justinbogner.com> wrote:
>> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:
>>> +    // Fall through and run the system linker - we could do a hard error here,
>>> +    // but we may as well try and see if it works.
>> I think it's better to have an error here. As is, if someone says to
>> use a particular linker, but it's not available, we may use a different
>> linker. In some cases, this is fine: we're able to link, so what's the
>> problem? I'm concerned that this will make certain problems hard to
>> debug, where we expect to use  particular linker, but some path problem
>> or the like leads to using another.
>> Is there an advantage to falling back to the system linker when somebody
>> explicitly asks for a different one?
> I don't have strong feelings here.  We report the error anyway, so I don't object to making it a hard failure.
> David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list