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

[David Chisnall]

The code seemed to work, the tests failed on Windows (I think because of something else in the driver that doesn't use the target platform's linker search paths when cross-compiling, even with -B specified), and I didn't have time to fix tests on a platform that I don't have access to.  The code was committed and reverted, so if you want to have a go at fixing the tests, you'd be welcome.  Otherwise, I'll hopefully get back to it in a few weeks (although it's further down the list than tidying up a load of MIPS back end fixes for upstreaming).

David

On 23 Jan 2014, at 15:28, Greg Fitzgerald <garious at gmail.com> wrote:

> Did this patch make it in?  Doesn't look like it.  What happened?
> 
> Thanks,
> Greg
> 
> 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