[cfe-dev] Adding -fuse-ld= support to clang
David Chisnall
David.Chisnall at cl.cam.ac.uk
Sun May 19 06:07:55 PDT 2013
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
More information about the cfe-dev
mailing list