This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forcing the linker to be a particular one (i.e. gold vs bfd)


On Wed, Jan 12, 2011 at 9:22 AM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/12/2011 06:16 PM, Ian Lance Taylor wrote:
>>
>> Vladimir Simonov<sv@sw.ru> ?writes:
>>
>>> 3. What for do we need --enable-gold in configure.ac and
>>> gcc_cv_gold/ORIGINAL_GOLD_FOR_TARGET,etc. in gcc/configure.ac,
>>> gcc/exec-tool.in?
>>> For "Single tree build"?
>>> Is this mode used widely? As I understand the most of people use separate
>>> binutils/gcc build. In separate build default linker is specified
>>> via binutils configure options. So we need not explicit gold support
>>> in gcc's configure process.
>>> Is "Single tree build" mode support important for gold developers?
>>
>> Single tree build mode is not important for gold developers, at least
>> not for me.
>>
>>
>>> 5. Ones we need to pass some options to collect2, what do you think
>>> about -Wc,OPTIONS_FOR_COLLECT2 interface into gcc? Like
>>> it is for -Wa/-Wl. "c" in -Wc means collect, may be -Wt is better
>>> to avoid confusion with "C" as language.
>>
>> I don't see a need for a special way to pass options to collect2. ?-Wl
>> will pass options to collect2 just fine. ?If there is some need, it
>> should not be -Wc, as libtool uses that to pass options to the compiler.
>>
>>
>> I don't personally care too much about this issue. ?At Google we just
>> install GNU ld in a different directory under the name "ld", and pass a
>> -B option to gcc if we want to use it. ?That approach doesn't require
>> any changes to any tools. ?I'm not opposed to installing the linkers
>> under different names and coming up with some way to tell the compiler
>> which linker to use, I just don't personally care about it all that
>> much.
>>
>> Ian
>>
> Thank you for replay.
>
>
> So, trying to simplify Nick's patch we may:
> 1. Eliminate --enable-gold related changes in configure.ac,
> gcc/configure.ac, gcc/exec-tool.in. I mean the patch, not
> original files.
>
> 2. Taking into account current binutils installation layout, I see
> two ways:
> 2.1 Add -Wl,--use-ld=LINKER_NAME support in collect2. collect2 will
> strip --use-ld=LINKER_NAME from linker options and call appropriate
> linker.
> 2.2 Leave gcc untouched and do the same work in binutils.
> If --enable-gold specified in binutils configure options we create
> simple wrapper which will strip --use-ld=LINKER_NAME from linker
> options and call appropriate linker. Default linker is defined
> by configure options. The wrapper is installed as ld.
> The wrapper code should be located in gold directory and built
> (and installed as ld) if "make" visits gold directory.
>
> Both have pro and contra. 2.2 - decreases binutils install size,
> leaves gcc untouched but adds additional "exec" during link process.
>
> I can try to do any.
> What do you think which is better?
>

I don't think we should go with 2.2.  GCC driver already sets

COLLECT_GCC=/usr/gcc-4.6/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'

Why not add

COLLECT_LINKER=..............

which can be set by "gcc -flinker=ld.gold|ld.bfd"?

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]