linux: use an in-tree copy of gold by default

linux: use an in-tree copy of gold by default

(Reland of r120385 with newer third_party/gold.)

Rather than forcing everyone to configure their search paths etc.
we should just make this work by default.  You can set
the gyp variable linux_use_gold_binary=0 to turn it off.

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

[bradn, 2012-01-31 18:53:01]

lgtm

https://chromiumcodereview.appspot.com/9316002/diff/1/DEPS
File DEPS (right):

https://chromiumcodereview.appspot.com/9316002/diff/1/DEPS#newcode413
DEPS:413: "/trunk/deps/third_party/gold@XXXXX",
Assuming XXXX becomes a real rev, LG.

[Evan Martin, 2012-01-31 18:56:17]

I worry this might break chromeos, but I'm not sure.

[bradn, 2012-01-31 19:00:37]

The key thing is whether they can run your build of gold in their chroot.
Having recently been involved in getting the nacl toolchain to run their (but
build elsewhere), my offhand thoughts are:
- Anything you can link in staticly will be make life easier
- Your probably ok as long as the ld.gold is 64-bit as the chroot is fairly
baroque.

[Evan Martin, 2012-01-31 19:03:28]

Antoine, can you comment on how I should set the defaults for ChromeOS?  I'm not
even sure about the host vs target thing.

For background, I'm trying to make it so people who Don't Care About Linux still
get gold by default when building.  The "ld" found in third_party/gold is a
64-bit binary.

[bradn, 2012-01-31 19:07:36]

https://chromiumcodereview.appspot.com/9316002/diff/5002/tools/licenses.py
File tools/licenses.py (right):

https://chromiumcodereview.appspot.com/9316002/diff/5002/tools/licenses.py#ne...
tools/licenses.py:66: os.path.join('third_party','gold'),
So last time I tried to add something to this list, Pawel got mad at me.
YMMV :-)

[piman, 2012-01-31 20:20:49]

On 2012/01/31 19:03:28, Evan Martin wrote:
> Antoine, can you comment on how I should set the defaults for ChromeOS?  I'm
not
> even sure about the host vs target thing.
> 
> For background, I'm trying to make it so people who Don't Care About Linux
still
> get gold by default when building.  The "ld" found in third_party/gold is a
> 64-bit binary.

A few things:
- I assume the linker you're going to put there is x86-only. You'll want to make
this conditional on target_arch==x86|x64
- you can use gold on the host. the host toolchain is actually more likely to be
a "conventional" one with which gold will work fine
- for chromeos, this may be disruptive, because we already uses a gold at the
system level, but possibly a different version (with a bunch of bugfixes). I'd
try not to touch the toolchain on chromeos. You can probably key it off
chromeos==1, which doesn't tell the whole story (we can compile chromeos=1
binaries on linux), but is a good first approximation

[Evan Martin, 2012-01-31 20:29:17]

PTAL

I basically want this on for the 90% case (Googler desktop running 64-bit Linux)
and off for anything complicated (everything else).

[Evan Martin, 2012-01-31 20:30:08]

https://chromiumcodereview.appspot.com/9316002/diff/5/build/common.gypi
File build/common.gypi (right):

https://chromiumcodereview.appspot.com/9316002/diff/5/build/common.gypi#newco...
build/common.gypi:398: # things complicated.
fixed this comment locally, but not re-uploading so the existing try job goes
through

[piman, 2012-01-31 20:34:33]

lgtm

[commit-bot: I haz the power, 2012-01-31 21:15:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/evan@chromium.org/9316002/5

[commit-bot: I haz the power, 2012-01-31 21:16:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/evan@chromium.org/9316002/8002

[Evan Martin, 2012-01-31 21:28:19]

Nico, my brilliant plan here is thwarted by the fact that the compile command
runs in some directory other than the source root.  Do you have any advice on
how to make this -B flag Do What I Want?  I see $(SOURCE_ROOT) in some gyp files
but it appears to be generator-specific.

[Nico, 2012-01-31 22:24:10]

https://chromiumcodereview.appspot.com/9316002/diff/8002/build/common.gypi
File build/common.gypi (right):

https://chromiumcodereview.appspot.com/9316002/diff/8002/build/common.gypi#ne...
build/common.gypi:2016: '-Bthird_party/gold',
Do

'variables': {
  'gold_path': 'third_party/gold'
}
'ldflags': {'-B<(variables)']

then gyp will Absolutize() (or GypToNinja() or what have you) the path to gold

[Nico, 2012-01-31 22:25:24]

(Search for 'tweak_info_plist_path' for an example.)

[Evan Martin, 2012-01-31 22:53:42]

PTAL, some gross hacks on the path

[Nico, 2012-01-31 22:57:11]

lgtm

[commit-bot: I haz the power, 2012-01-31 23:02:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/evan@chromium.org/9316002/11

[Nico, 2012-02-01 00:15:55]

(Mostly curious, you can land as is anyway.)

http://codereview.chromium.org/9316002/diff/11/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/9316002/diff/11/build/common.gypi#newcode2019
build/common.gypi:2019: 'gold_path': '<(PRODUCT_DIR)/../../third_party/gold',
Would '<(DEPTH)/third_party/gold' work as well?

[Evan Martin, 2012-02-01 00:17:21]

On 2012/02/01 00:15:55, Nico wrote:
> build/common.gypi:2019: 'gold_path': '<(PRODUCT_DIR)/../../third_party/gold',
> Would '<(DEPTH)/third_party/gold' work as well?

I tried that, but <(DEPTH) results in a source-relative path as well.

[commit-bot: I haz the power, 2012-02-01 00:57:04]

Try job failure for 9316002-11 (retry) on mac_rel for step "browser_tests".
It's a second try, previously, step "browser_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[Evan Martin, 2012-02-03 19:50:23]

Same patch as before, but with newer third_party/gold that has a hacky
workaround for 64-bit kernel + 32-bit userland.

[Nico, 2012-02-03 19:53:50]

still lgtm

I guess we have no 32bit trybots, so you might as well just land :-/