Hi Everyone,
In FreeBSD, we are about to start the process of migrating from (ancient) BFD ld to MCLinker, so we're going to need support for multiple linkers for a while. It turns out that gcc already has an option to select linkers, so I have attempted to remain compatible in the attached patch. This adds a -fuse-ld={name} option, which takes a string as an argument. The toolchains then request a linker and get either ld.{name}, ld-{name}, or {name} as the linker.
Does anyone have objections to committing this as-is, or would anyone like to recommend a better approach?
David
Index: include/clang/Basic/DiagnosticDriverKinds.td
Hi Everyone,
In FreeBSD, we are about to start the process of migrating from (ancient) BFD ld to MCLinker, so we're going to need support for multiple linkers for a while. It turns out that gcc already has an option to select linkers, so I have attempted to remain compatible in the attached patch. This adds a -fuse-ld={name} option, which takes a string as an argument. The toolchains then request a linker and get either ld.{name}, ld-{name}, or {name} as the linker.
Does anyone have objections to committing this as-is, or would anyone like to recommend a better approach?
Looks fairly reasonable, but
* Instead of running touch, add the file to the install tree in svn.
* Test both ld.name and ld-name.
* If there is both ld.name and ld-name, make sure and test we select
the same one as gcc.
Looks fairly reasonable, but
* Instead of running touch, add the file to the install tree in svn.
* Test both ld.name and ld-name.
Makes sense.
* If there is both ld.name and ld-name, make sure and test we select
the same one as gcc.
Can someone who doesn't mind going near GPLv3 code please tell me what GCC does in this case? I have only looked at the documentation. I believe that they just hard-code the names for ld.bfd and ld.gold, but I am not certain.
David
David Chisnall <David.Chisnall@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?
Fencepost comment, but does it ever make sense to respect LD in env?
Looks fairly reasonable, but
* Instead of running touch, add the file to the install tree in svn.
* Test both ld.name and ld-name.
Makes sense.
Note, gcc does not look for ld-gold or ld-bfd, only for ld.gold and ld.bfd.
* If there is both ld.name and ld-name, make sure and test we select
the same one as gcc.
Can someone who doesn't mind going near GPLv3 code please tell me what GCC does in this case? I have only looked at the documentation. I believe that they just hard-code the names for ld.bfd and ld.gold, but I am not certain.
Yes, they search for linkers with suffix "ld", a configure time optional $PLUGIN_LD_SUFFIX, "ld.gold" and lastly "ld.bfd".
-Dimitry
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.
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.
Did this patch make it in? Doesn't look like it. What happened?
Thanks,
Greg
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