PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
Tue Jan 5 23:48:00 GMT 2010
On 05.01.2010 23:29, Ian Lance Taylor wrote:
> "H.J. Lu"<email@example.com> writes:
>> On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor<firstname.lastname@example.org> wrote:
>>> Roland McGrath<email@example.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
>>>> 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
>> 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.
More information about the Binutils