[cfe-dev] Adding -fuse-ld= support to clang
David.Chisnall at cl.cam.ac.uk
Thu Jan 23 15:32:19 PST 2014
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).
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?
> 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.
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
More information about the cfe-dev