Don't add -fuse-ld=gold to cflags

Don't add -fuse-ld=gold to cflags

Don't add -fuse-ld=gold to cflags, since gyp emits ninja files that
compile with -c, which means the linker is not used, making the flag
useless.

Removing ignored options makes the compiler commands (slightly)
easier to read, and can avoid some errors in mismatched icecc setups.

BUG=352046
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=268377

[Mostyn Bramley-Moore, 2014-05-05 08:06:03]

@mithro, Nico et al: please take a look.

[mithro-old, 2014-05-05 14:44:15]

On 2014/05/05 08:06:03, Mostyn Bramley-Moore wrote:
> @mithro, Nico et al: please take a look.

It is my understanding that -fuse-ld=gold can/could affect the compiler output.

[Mostyn Bramley-Moore, 2014-05-05 14:58:00]

On 2014/05/05 14:44:15, mithro wrote:
> On 2014/05/05 08:06:03, Mostyn Bramley-Moore wrote:
> > @mithro, Nico et al: please take a look.
> 
> It is my understanding that -fuse-ld=gold can/could affect the compiler
output.

In what way?  Do you have any examples I can take a look at?

The GCC docs say that -c instructs gcc to "Compile or assemble the source files,
but do not link. The linking stage simply is not done."
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html

And that -fuse-ld=gold tells gcc to "Use the gold linker instead of the default
linker."
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html

[Nico, 2014-05-05 15:41:57]

As far as I can tell, -fuse-ld was added in
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=194983 and at
least as of 4.8.2 isn't used in files other than the ones touched in
that commit. It looks like the only thing it does is select the linker
command to invoke when invoking a linker, so this change looks correct
to me.

On Mon, May 5, 2014 at 7:58 AM,  <mostynb@opera.com> wrote:
> On 2014/05/05 14:44:15, mithro wrote:
>>
>> On 2014/05/05 08:06:03, Mostyn Bramley-Moore wrote:
>> > @mithro, Nico et al: please take a look.
>
>
>> It is my understanding that -fuse-ld=gold can/could affect the compiler
>
> output.
>
> In what way?  Do you have any examples I can take a look at?
>
> The GCC docs say that -c instructs gcc to "Compile or assemble the source
> files,
> but do not link. The linking stage simply is not done."
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html
>
> And that -fuse-ld=gold tells gcc to "Use the gold linker instead of the
> default
> linker."
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html
>
> https://codereview.chromium.org/265263002/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[mithro-old, 2014-05-05 15:56:11]

I don't have any proof that it is *actually* needed. The best I found was
the patch to clang (which got reverted) seem to make dwarf-4 be default
when gold was the linker (instead of dwarf-3).

There are also some linker flags which need to be given at both compiler
and link time. An example is -flto which needs to be given to "needs to be
specified at compile time and during the final link" according to the
documentation.

Tim


On 5 May 2014 07:58, <mostynb@opera.com> wrote:

> On 2014/05/05 14:44:15, mithro wrote:
>
>> On 2014/05/05 08:06:03, Mostyn Bramley-Moore wrote:
>> > @mithro, Nico et al: please take a look.
>>
>
>  It is my understanding that -fuse-ld=gold can/could affect the compiler
>>
> output.
>
> In what way?  Do you have any examples I can take a look at?
>
> The GCC docs say that -c instructs gcc to "Compile or assemble the source
> files,
> but do not link. The linking stage simply is not done."
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html
>
> And that -fuse-ld=gold tells gcc to "Use the gold linker instead of the
> default
> linker."
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html
>
> https://codereview.chromium.org/265263002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mostyn Bramley-Moore, 2014-05-05 17:08:01]

On 2014/05/05 15:56:11, mithro wrote:
> I don't have any proof that it is *actually* needed. The best I found was
> the patch to clang (which got reverted) seem to make dwarf-4 be default
> when gold was the linker (instead of dwarf-3).
> 
> There are also some linker flags which need to be given at both compiler
> and link time. An example is -flto which needs to be given to "needs to be
> specified at compile time and during the final link" according to the
> documentation.

I believe -flto does different things in the compile and link steps, and it
doesn't use the linker during the compile step- it just writes data to some
extra ELF sections in the object file.  

You can confirm this by comparing the output from these two commands:
gcc -flto -fuse-ld=gold -c test.c -v
gcc -flto -fuse-ld=gold test.c -v

Also, using -flto works with icecc, which doesn't even distribute the linker. 
Test commands (I won't paste the output here, but the debug logs show the file
being compiled remotely):
export ICECC_DEBUG=debug
icecc gcc -c -flto -fuse-ld-gold test.c

[mithro-old, 2014-05-05 17:20:44]

My argument was *not* that the linker is used during the compile step.

My argument was that the choice of linker could effect how and what the
compiler does during compile. (Just like how -flto does.)

As you have pointed out we don't have any proof at the moment that this is
the case, so its probably not worth worrying about.

Tim
On 5 May 2014 10:08, <mostynb@opera.com> wrote:

> On 2014/05/05 15:56:11, mithro wrote:
>
>> I don't have any proof that it is *actually* needed. The best I found was
>> the patch to clang (which got reverted) seem to make dwarf-4 be default
>> when gold was the linker (instead of dwarf-3).
>>
>
>  There are also some linker flags which need to be given at both compiler
>> and link time. An example is -flto which needs to be given to "needs to be
>> specified at compile time and during the final link" according to the
>> documentation.
>>
>
> I believe -flto does different things in the compile and link steps, and it
> doesn't use the linker during the compile step- it just writes data to some
> extra ELF sections in the object file.
>
> You can confirm this by comparing the output from these two commands:
> gcc -flto -fuse-ld=gold -c test.c -v
> gcc -flto -fuse-ld=gold test.c -v
>
> Also, using -flto works with icecc, which doesn't even distribute the
> linker.
> Test commands (I won't paste the output here, but the debug logs show the
> file
> being compiled remotely):
> export ICECC_DEBUG=debug
> icecc gcc -c -flto -fuse-ld-gold test.c
>
> https://codereview.chromium.org/265263002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-05-05 17:22:39]

lgtm

Ideally add some explanation why this is a desirable change (I'm guessing it's
"icecc is happier this way"?), as the change has a small cost. (The risk of
-fuse-ld possibly affecting compiler behavior in future compilers.)

[mithro-old, 2014-05-05 17:30:21]

On 2014/05/05 17:22:39, Nico wrote:
> lgtm
> 
> Ideally add some explanation why this is a desirable change (I'm guessing it's
> "icecc is happier this way"?), as the change has a small cost. (The risk of
> -fuse-ld possibly affecting compiler behavior in future compilers.)

LGTM

(Please fix caps in the first line :)

[Mostyn Bramley-Moore, 2014-05-05 17:47:55]

Description updated.

[Mostyn Bramley-Moore, 2014-05-05 17:47:59]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-05-05 17:48:58]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mostynb@opera.com/265263002/1

[mithro-old, 2014-05-05 17:49:41]

On 2014/05/05 17:47:59, Mostyn Bramley-Moore wrote:
> The CQ bit was checked by mailto:mostynb@opera.com

Just a FYI, you might want to check with the Android guys on why they added the
-fuse-ld=gold to cflags/ldflags.

[Mostyn Bramley-Moore, 2014-05-05 17:53:34]

The CQ bit was unchecked by mostynb@opera.com

[Mostyn Bramley-Moore, 2014-05-05 17:54:04]

On 2014/05/05 17:49:41, mithro wrote:
> On 2014/05/05 17:47:59, Mostyn Bramley-Moore wrote:
> > The CQ bit was checked by mailto:mostynb@opera.com
> 
> Just a FYI, you might want to check with the Android guys on why they added
the
> -fuse-ld=gold to cflags/ldflags.

Right- unchecked the CQ bit for now.

[mithro-old, 2014-05-05 18:00:13]

On 2014/05/05 17:54:04, Mostyn Bramley-Moore wrote:
> On 2014/05/05 17:49:41, mithro wrote:
> > On 2014/05/05 17:47:59, Mostyn Bramley-Moore wrote:
> > > The CQ bit was checked by mailto:mostynb@opera.com
> > 
> > Just a FYI, you might want to check with the Android guys on why they added
> the
> > -fuse-ld=gold to cflags/ldflags.
> 
> Right- unchecked the CQ bit for now.

They started using the flag before I made the change for everyone to start using
it (which is probably where I got the idea from).

[Mostyn Bramley-Moore, 2014-05-05 18:53:45]

@Shouqun, bulach: do the android parts of this look OK to you?  This was added
in this earlier CL: https://chromiumcodereview.appspot.com/12942010

[Shouqun, 2014-05-06 01:28:10]

On 2014/05/05 18:53:45, Mostyn Bramley-Moore wrote:
> @Shouqun, bulach: do the android parts of this look OK to you?  This was added
> in this earlier CL: https://chromiumcodereview.appspot.com/12942010

lgtm

[Nico, 2014-05-06 02:46:37]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2014-05-06 02:48:14]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mostynb@opera.com/265263002/1

[commit-bot: I haz the power, 2014-05-06 02:57:38]

Change committed as 268377

[bulach, 2014-05-06 13:50:36]

late lgtm, thanks for the cleanup!