On 05.01.2010 23:29, Ian Lance Taylor wrote:
"H.J. Lu"<hjl.to...@gmail.com> writes:
On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor<i...@google.com> wrote:
Roland McGrath<rol...@redhat.com> writes:
I'm still not entirely convinced that this is the way to go. It seems
to me that ideally one wants to be able to select the linker at
runtime. I don't see how this patch supports that. What am I
missing?
It covers the first step by letting you run "ld.bfd" or "ld.gold" to
choose. Having the two binaries installed by those names is a good start
and seems likely to be part of how any fancier plan would work, so why not
start there?
Mainly because an alternative is to install them in subdirectories
with the name ld. Then gcc can run them directly using a -B option.
I don't know which approach is best.
Plugin only works with gold. So I configured my gcc with
-with-plugin-ld=ld.gold
If both linkers have the same name, it will be harder to
use ld by default and use gold only for plugin.
The issue can be addressed with symlinks.
Of course, if we have a way to tell gcc the linker to use, by name, at
runtime, that will also work.
symlinks are only a solution for a globally configured default. when building a
package which requires a specific linker, you'll have to work with explicit
build-depends/build-conflicts which need package installation/removal for
building a single package. this might be feasible for a machine used by a single
developer, but not for a machine where you don't have root access, and you still
want to be able to use both ld versions. For this kind of setup an option
interpreted by the gcc driver like --ld=<ld> would be useful. even managing this
symlink with alternatives or diversions gives you the flexibility.
Matthias
