If I dont use "chrome_internal" then I am able to reproduce the issue reported in here. So, it seems there is another issue when you use "chrome_internal"

Right, sorry about any confusion. I think we should focus on:

USE="gn -build_tests -chrome_internal", i.e. one problem at a time...

Speaking of isolating the problem,  I compared the args.gn between chroot and simplechrome and one difference is component_build. We're setting that to true in the chroot (see issue 595763). I'm going to try with -chrome_debug.

Unrelated, still fails.

BTW, here is what args.gn looks like in the chroot with BOARX=x86-generic:

$ cat /var/cache/chromeos-chrome/chrome-src/src/out_$BOARD/Release/args.gn 
is_asan = false
target_cpu = "x86"
ozone_auto_platforms = false
enable_nacl = true
ozone_platform_gbm = true
cros_target_ar = "i686-pc-linux-gnu-ar"
use_v4l2_codec = true
cros_target_cxx = "i686-pc-linux-gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold"
is_clang = false
pkg_config = "/build/x86-generic/build/bin/pkg-config"
cros_target_cc = "i686-pc-linux-gnu-gcc -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold"
target_sysroot = "/build/x86-generic"
system_libdir = "lib"
use_evdev_gestures = true
use_cras = true
use_debug_fission = false
use_system_minigbm = true
ozone_platform = "gbm"
is_debug = false
use_v4lplugin = false
use_ozone = true
clang_use_chrome_plugins = false
enable_remoting = true
linux_use_bundled_binutils = false
use_system_harfbuzz = true
use_xkbcommon = true
icu_use_data_file = true
target_os = "chromeos"

So, a normal chrome build uses multiple toolchains, and in a cross-compile build those toolchains include:

- the 'default_toolchain' (the one building most things for the target)
- the 'host_toolchain' (which builds most things that run need to run on the host as part of the build, and also is used for helper binaries in some test suites)
- various nacl-related toolchains 
- the 'snapshot_toolchain' that v8 uses, which is like the host_toolchain except it needs to generate code that has the same bit-width as the target device, in other words, if you're building for a 32-bit arm or 32-bit x86 board, you need to use the 32-bit x86 toolchain for the snapshot, which is run on the host.

The 'is_clang' flag, when set, *only applies to the default_toolchain*. This means that the host and default toolchains, by default, will still try to use clang. This can be overridden by explicitly setting the 'host_toolchain' and 'snapshot_toolchain' GN args to, e.g., '//build/toolchain/linux:x64' and '//build/toolchain/linux:x86', if you need to use gcc for host binaries (assuming those defaults will work).

The fact that is_clang only applies to the target is something we thought might be a good idea at one point, but I now suspect that that might've been a mistake, because it seems like most people want to enforce that if we're using gcc for the target we use it on the host as well and so we should probably make that easier.

I think the error you're seeing is probably due to libicuuc being compiled using the snapshot toolchain for the v8 snapshot, though I can't be positive w/o seeing the actual gn args being used in the build (and maybe the full compile log).

The GN args are in comment #25

So, is the correct thing to do then in snapshot_toolchain.gypi:

if (host_cpu == "x64" && host_os == "linux" && target_os != "chromeos") {

?

nice description and comments at #26 dpranke

I did a little bit of investigation on the problems we are having building chromeos with GN.

the GN invocation seems correct:

/home/llozano/depot_tools/gn gen /var/cache/chromeos-cache/distfiles/target/chrome-src/src/c/Release --args=is_debug=false  use_v4l2_codec=true use_v4lplugin=false use_ozone=true use_evdev_gestures=true use_xkbcommon=true linux_use_bundled_binutils=false use_debug_fission=false enable_remoting=true enable_nacl=true icu_use_data_file=true use_cras=true use_system_harfbuzz=true is_asan=false is_clang=false clang_use_chrome_plugins=false ozone_auto_platforms=false ozone_platform_gbm=true use_system_minigbm=true is_component_build=true symbol_level=2 target_sysroot="/build/x86-alex" system_libdir="lib" pkg_config="/build/x86-alex/build/bin/pkg-config" target_os="chromeos" ozone_platform="gbm" target_cpu="x86" cros_target_ar="i686-pc-linux-gnu-ar" cros_target_cc="i686-pc-linux-gnu-gcc -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold" cros_target_cxx="i686-pc-linux-gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold" --root=/var/cache/chromeos-cache/distfiles/target/chrome-src/src

we are setting the cros compilers correctly. 

However, from the start of the build, there are some packages that are using the wrong compiler.

before the build breaks, 10314 compiles happen with GCC,
while 1066 are happening with clang which is incorrect. 

Some of the packages that are using the wrong compilers:
- breakpad
- protobuf
- native-client
- icu

(I could give the full list for the partial build)

I also believe the host compiles are ignoring the setting for the host compiler, since they seem to be using clang. 

I am too new to GN to know what is going on yet.

I found a problem in BUILDCONFING.gn

declare_args() {
  # Component build.
  is_component_build = false

  # Debug build.
  is_debug = true

  # Whether we're a traditional desktop unix.
  is_desktop_linux = current_os == "linux"

  # Set to true when compiling with the Clang compiler. Typically this is used
  # to configure warnings.
  is_clang = current_os == "mac" || current_os == "ios" ||
             current_os == "linux" || current_os == "chromeos"


Clang is not default on ChromeOS.

Not sure if this part of the config is being exercised but we should remove this code just to make sure that noone thinks clang is default in chromeos.

So I tried this:

https://codereview.chromium.org/1952973004/

And it seems to work inside the chroot, but now I get this in Simple Chrome:


[13521/27284] ACTION //v8:run_mksnapshot(//build/toolchain/cros:target)
FAILED: gen/v8/snapshot.cc snapshot_blob.bin 
python ../../v8/tools/run.py ./mksnapshot --startup_src gen/v8/snapshot.cc --random-seed 314159265 --startup_blob snapshot_blob.bin
./mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./mksnapshot)
[13538/27284] ACTION //third_party/ffmpeg:ffmpeg_yasm_action(//build/toolchain/cros:target)
ninja: build stopped: subcommand failed.

Is that error from an arm target, or an x86 target ?

I think your change causes the snapshot toolchain to use the default toolchain for cros, which won't work for arm targets (default == target, and you need a host toolchain).

> Not sure if this part of the config is being exercised but we should remove this code just to make sure that noone thinks clang is default in chromeos.
Clang is used by default when building Chrome OS flavored Linux Chrome which is what you get when building Linux Chrome just by adding target_os=="chromeos", and this is the same thing as what GYP does.
Because is_clang=false is added to your args.gn if you follow the simple chrome instruction by running gn gen with --args="$GN_ARGS", there is no need to change that part of BUILDCONFIG.gn.

In  issue 588080 , I guessed GYP's host_clang was not needed in GN but it seems we actually need it?
Isn't it feasible to add host_clang to our GN code and let it use GCC if host_clang==false?
Please note that it seems you have to force host_clang=true in cros_chrome_sdk.py for simple chrome as it does for the corresponding GYP parameter.

Re-assigning this to dpranke@ since this is clearly GN related, not a toolchain issue (other than that we are using the wrong toolchain).

I will do my best to continue to poke feebly at the problem until Dirk has cycles.

@stevenjb - did you see my comment in #32? 

@34, Hashimoto, I dont understand your comment about clang being default for CHromeOS
. Clang is not default for any configuration of chromeos (not yet)

dpranke@ - Is which error for an arm or x86 target?

I am poking at things I don't understand and I don't think it's being very helpful.

I was able to get a chroot build of x86-generic to "work" by tweaking snapshot_toolchain.gni to use 'snapshot_toolchain = default_toolchain' when target_os == "chromeos", but that is almost certainly not the correct solution.

Also, as llozano pointed out that would only address the nacl compilation. We still build other targets (e.g. breakpad) with clang in the chroot and we should not.

It does sound like we need something along the lines of "host_clang = false" in GN for chromeos and fix all of the places where we default to clang for linux (without checking for chromeos), but from my perspective that seems like needle-in-haystack land except that I don't know quite what the needle looks like :)

Hm. Okay, if you're building for an x86 board, I'm not sure why you'd get those errors, but they may be related to how the sysroots are getting configured.

@stevenjb - is it easy to try a build w/o your change from #31, but with setting host_toolchain="//build/toolchain/linux:x64" and snapshot_toolchain="//build/toolchain/linux:x86" in your GN args?

I'm not sure if that'll hit sysroot-related errors or not. But, if you do, I would at least initially expect a host_clang=false setting to also hit the same errors (i.e., host_clang=false should produce the same result as setting those two args, I think).

That said, I agree that host_clang is probably the right thing to do and I'll post a CL for that ASAP to unblock things.

I tried setting host|snapshot_toolcahin but get this:

ERROR at //v8/BUILD.gn:18:1: Value collision.
import("snapshot_toolchain.gni")
^------------------------------
This import contains "snapshot_toolchain"
See //v8/snapshot_toolchain.gni:36:26: defined here.
    snapshot_toolchain = "//build/toolchain/linux:clang_x86"
                         ^----------------------------------
Which would clobber the one in your current scope
See the command-line "--args":1:396: defined here.
is_debug=false  use_v4l2_codec=true use_v4lplugin=false use_ozone=true use_evdev_gestures=true use_xkbcommon=true linux_use_bundled_binutils=false use_debug_fission=false enable_remoting=true enable_nacl=true icu_use_data_file=true use_cras=true use_system_harfbuzz=true is_asan=false is_clang=false clang_use_chrome_plugins=false host_toolchain="//build/toolchain/linux:x64" snapshot_toolchain="//build/toolchain/linux:x86" ozone_auto_platforms=false ozone_platform_gbm=true use_system_minigbm=true is_component_build=true symbol_level=2 target_sysroot="/build/x86-generic" system_libdir="lib" pkg_config="/build/x86-generic/build/bin/pkg-config" target_os="chromeos" ozone_platform="gbm" target_cpu="x86" cros_target_ar="i686-pc-linux-gnu-ar" cros_target_cc="i686-pc-linux-gnu-gcc -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold" cros_target_cxx="i686-pc-linux-gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold"

oh, argh. I misread that file; I thought it was wrapped in a declare_args() block. Maybe try that?

I do not understand your suggestion.

When we build chrome for chromeos in the chroot, we run something like:

$ cros_workon --board=${BOARD} start chromeos-chrome    ### Use the -9999.ebuild file
$ USE="gn build_tests chrome_internal" emerge-${BOARD} chromeos-chrome

This runs the chromeos-chrome-9999.ebuild script which does many things, including:
* Generates a BUILD_ARGS variable
* Sets GN_ARGS="${BUILD_ARGS[*]}"
* Runs: gn gen "${CHROME_ROOT}/src/${BUILD_OUT_SYM}/${BUILDTYPE}" \
               --args="${GN_ARGS}" --root="${CHROME_ROOT}/src"
* Builds chrome
* Deploys chrome to a staging directory

I mean, can you try modifying snapshot_toolchain.gni so that the entire thing is wrapped in a declare_args() { ... } block?

That will help me figure out if I understand the problem or not. Hopefully I will be caught up enough later this afternoon to try to repro this myself, also ...

I still haven't been able to make much progress on this.

I wrapped snapshot_toolchain.gni in a declare_args() {} block, but setting host_toolchain="//build/toolchain/linux:x64" and snapshot_toolchain="//build/toolchain/linux:x86" in the ebuild results in:

"No such file or directory" errors for <bits/predefs.h>, <sys/types.h>, and possibly others.

Also, I just remembered that I had to disable an assert with the following comment which may be related:

    # Our sysroot images only contains gcc 4.6 headers, but chromium requires
    # gcc 4.9. Clang is able to detect and work with the 4.6 headers while
    # gcc is not. This check can be removed if we ever update to a more modern
    # sysroot.
    assert(is_clang, "sysroot images require clang (try use_sysroot=false)")

Okay, after talking to Brett a bit he still wants to avoid adding a 'host_clang' variable if possible.

I've posted a couple of CLs that should make this doable by just tweaking the defaults
to work better for CrOS cross-compiles:

https://codereview.chromium.org/1969693002/
https://codereview.chromium.org/1964303002/

I think that if you apply these two patches and *also* specify `use_sysroot = false` in your GN args list the compile should work fine and never try to use clang.

I haven't yet had time to set up an ebuild-based build, so I haven't verified the full set of args yet locally. 

@stevenjb - is this something you can try yet again?

I just quickly tried this #46. 

however, this seems to be using the wrong host compiler? g++ vs x86_64... 
see below:

Skipping gyp_chromium due to GYP_CHROMIUM_NO_ACTION env var.
^[[0mLAL: /home/llozano/depot_tools/gn gen /home/llozano/chrome_root/src/c/Release --args=is_debug=false  use_v4l2_codec=true use_v4lplugin=false use_ozone=true use_evdev_gestures=true use_xkbcommon=true linux_use_bundled_binutils=false use_debug_fission=false enable_remoting=true enable_nacl=true icu_use_data_file=true use_cras=true use_system_harfbuzz=true is_asan=false is_clang=false clang_use_chrome_plugins=false ozone_auto_platforms=false ozone_platform_gbm=true use_system_minigbm=true is_component_build=true symbol_level=2 target_sysroot="/build/x86-alex" system_libdir="lib" pkg_config="/build/x86-alex/build/bin/pkg-config" target_os="chromeos" ozone_platform="gbm" target_cpu="x86" cros_target_ar="i686-pc-linux-gnu-ar" cros_target_cc="i686-pc-linux-gnu-gcc -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold" cros_target_cxx="i686-pc-linux-gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold" use_sysroot=false  --root=/home/llozano/chrome_root/src
^[[32mDone. ^[[0mWrote 5698 targets from 942 files in 1641ms
>>> Source configured.
>>> Compiling source in /build/x86-alex/tmp/portage/chromeos-base/chromeos-chrome-52.0.2723.2_rc-r1/work/chromeos-chrome-52.0.2723.2_rc ...
ninja: Entering directory `c/Release'
[1/28040] g++ -MMD -MF x64/obj/breakpad/stackwalk_common/stackwalker_amd64.o.d -DBPLOG_MINIMUM_SEVERITY=SEVERITY_ERROR -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_TOPCHROME_MD=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCOMPONENT_BUILD -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../../../../../../home/llozano/chrome_root/src -Ix64/gen -I../../../../../../../home/llozano/chrome_root/src/breakpad/src -I../../../../../../../home/llozano/chrome_root/src/breakpad/src/third_party -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 -O2 -fno-ident -fdata-sections -ffunction-sections -g2 -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11 -fno-rtti -fno-exceptions -Wno-deprecated -Wno-narrowing -c ../../../../../../../home/llozano/chrome_root/src/breakpad/src/processor/stackwalker_amd64.cc -o x64/obj/breakpad/stackwalk_common/stackwalker_amd64.o

in the ebuild we are doing the following for the host compiler:

        export CC_host=$(usex clang "clang" "$(tc-getBUILD_CC)")
        export CXX_host=$(usex clang "clang++" "$(tc-getBUILD_CXX)")
        export AR_host=$(tc-getBUILD_AR)

however, I don't see this being passed to GN in any GN env vars (see GN command at #47.

how do we specify the host compiler for GN?

@llozano wrote:
> how do we specify the host compiler for GN?

Good question. You currently can't :(.

I don't think I paid enough attention to how you were setting things up before and had naively assumed that picking up 'gcc' and 'g++' from the path was good enough from inside the chroot.

However, we probably need equivalents to cros_target_cc et. al to be specified in //build/toolchain/cros/BUILD.gn and you might need something similar for the snapshot :(.

I'll look at this further today.

I looked from some more differences in the way we invoke gyp and GN and the output logs.. some things I noticed:

1) from the ebuild, I noticed we are using the following environment variables

AS RANLIB STRIP
LD LD_host
{C,CXX,CPP,LD}FLAGS



that were not mapped to any GYP variables and were probably consumed by GYP as environment variables. Some of these we have already discussed. I though I would 
be good to collect the list. 

there is also these, which I dont know if they matter for GN.

BOTO_CONFIG
DEPOT_TOOLS_GSUTIL_BIN_DIR

2) Also, when building with gyp, I see some differences related to nacl. 
With GN I see some invocations of ../native_client/toolchain/linux_x86/pnacl_newlib/bin/x86_64-nacl-clang++

while with GYP I see some invocations of a tool build_nexe.
Is 2) expected?

Re: 1) Yes, some of those things may have been used in GYP, though I'm not sure which besides maybe LD, LD_host, and LDFLAGS actually have an effect.

GN won't look at or honor env vars, so you'll need to convert them into GN arg equivalents if you actually need them.

If it turns out that you basically need to specify every aspect of your toolchain, we might just want to switch to a model where you generate the toolchain file directly.

yes. I was assuming we would need to use GN variables (args) for these. I just wanted to give you the list so that you can tell us how to pass to GN. 

Can you confirm that you really need all of them? It doesn't look to me like GYP would use most of them either, but it's possible I missed something when looking at the GYP code.

I am probably just doing the same you did. ie: browsing the gyp code.

definetly looks like these ones were supported:

{C,CXX,CPP,LD}FLAGS
{C,CXX,CPP,LD}FLAGS_host

{CC,CXX,AR}_host

also, chrome ebuild sets PATH like this,
export PATH=${PATH}:/home/$(whoami)/depot_tools

and it seems GYP looks at PATH?

I think that is it..

Okay, I have uploaded a couple of patches (one to chromium, one to v8) that I think
will get us working:

https://codereview.chromium.org/1983613002/
https://codereview.chromium.org/1979883002/

See the CL description in the first one for more info, but basically we'll need to add a couple more GN_ARGS to make the v8 snapshot and host toolchains work properly. These CLs also should add all of the extra flag args that are needed, but does not add anything for controlling the PATH, since I have no idea what's required there or why yet.

testing with the following settings. Testing is going fine... but need to go to bed.

take a look and see if makes sense. In particular for the v8 settings.

	BUILD_STRING_ARGS+=(
		cros_target_ar="${AR}"
		cros_target_cc="${CC}"
		cros_target_cxx="${CXX}"
	)
	if use gn; then
	        BUILD_ARGS+=( cros_host_is_clang=$(usetf clang) )
	        BUILD_STRING_ARGS+=(
			host_toolchain="//build/toolchain/cros:host"
  			v8_snapshot_toolchain="//build/toolchain/cros:v8_snapshot"
		      	cros_target_ld="${LD}"
		      	cros_target_extra_cflags="${CFLAGS}"
		      	cros_target_extra_cppflags="${CPPFLAGS}"
		      	cros_target_extra_cxxflags="${CXXFLAGS}"
		      	cros_target_extra_ldflags="${LDFLAGS}"
		      	cros_host_cc="${CC_host}"
		      	cros_host_cxx="${CXX_host}"
		      	cros_host_ar="${AR_host}"
		      	cros_host_ld="${LD_host}"
		      	cros_host_extra_cflags="${CFLAGS_host}"
		      	cros_host_extra_cxxflags="${CXXFLAGS_host}"
		      	cros_host_extra_cppflags="${CPPFLAGS_host}"
		      	cros_host_extra_ldflags="${LDFLAGS_host}"
			)
		if use x86 || use arm; then
		        # cros_vs_snapshot_ld??
		       	BUILD_STRING_ARGS+=(   
		      	     cros_v8_snapshot_extra_cflags="-m32"
			     cros_v8_snapshot_extra_cxxflags="-m32"
		      )
		fi
	fi	

this finished building and it seems cxxflags cflags were being passed correctly.

HOwever, at the end the ebuild is doing some verification and it does not like this:

scanelf: rpath_security_checks(): Security problem with DT_RPATH='$ORIGIN/.' in /build/x86-alex/tmp/portage/chromeos-base/chromeos-chrome-52.0.2723.2_rc-r1/image/opt/google/chrome/chrome-sandbox with mode set of 4755
scanelf: rpath_security_checks(): Security problem with DT_RPATH='$ORIGIN/.' in /build/x86-alex/tmp/portage/chromeos-base/chromeos-chrome-52.0.2723.2_rc-r1/image/opt/google/chrome/chrome-sandbox with mode set of 4755

 * QA Notice: The following files contain insecure RUNPATHs
 *  Please file a bug about this at http://bugs.gentoo.org/
 *  with the maintaining herd of the package.
 * $ORIGIN/. /build/x86-alex/tmp/portage/chromeos-base/chromeos-chrome-52.0.2723.2_rc-r1/image/opt/google/chrome/chrome-sandbox

investigating

using $ORIGIN in a set*id binary is a security problem.  you can create a hardlink to it and get it to load arbitrary code by creating your own shared libs in the same path.

yes. This bug has been found before:

https://bugs.chromium.org/p/chromium/issues/detail?id=556843

there are 14 link lines with $ORIGIN for rpath. 

An example link line is:

[984/24650] i686-pc-linux-gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.25.51-gold -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -B../../../../../../../home/llozano/chrome_root/src/third_party/binutils/Linux_x64/Release/bin -fuse-ld=gold -Wl,--icf=safe -pthread -m32 -Wl,-O1 -Wl,--gc-sections -Wl,--as-needed --sysroot=../../../../../../../build/x86-alex -L/build/x86-alex/lib\ -Wl,-rpath-link=/build/x86-alex/lib\ -L/build/x86-alex/usr/lib\ -Wl,-rpath-link=/build/x86-alex/usr/lib\ -L/build/x86-alex/usr/local/lib\ -Wl,-rpath-link=/build/x86-alex/usr/local/lib\ -L/build/x86-alex/usr/i686-pc-linux-gnu/lib\ -Wl,-rpath-link=/build/x86-alex/usr/i686-pc-linux-gnu/lib -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$ORIGIN/. -Wl,-rpath-link=. -Wl,-O1 -Wl,-O2 -Wl,--as-needed -o "./chrome_sandbox" -Wl,--start-group @"./chrome_sandbox.rsp"  -Wl,--end-group  -ldl -lrt 

It's not obvious to me where that would be coming from (I'm aware of the bug, seeing as how I filed it ;).

Can you post your args.gn contents? Are you doing a component build or using the sanitizer flags, perchance?

In my stock chromeos build (target_os="chromeos" use_debug=false), chrome_sandbox does not have a $ORIGIN in it. There are some targets (like base_unittests) that do, because they have to have it in order for the tests to pass.

using $ORIGIN w/local tests or non-installed programs is perfectly fine.  it's also OK to use it w/programs that aren't set*id.  but it's an error to use $ORIGIN w/set*id -- this applies to all Linux systems and not just CrOS.

@vapier: I'm unclear what your comment #64 is in response to. AFAIK, you and I are in agreement, so maybe you're attempting to say that most of the 14 link lines in #61 are okay?

notice that for #61, this only happens when doing component build.. 

I am testing this CL:

https://chromium-review.googlesource.com/#/c/345471/3

And everything seems much better.. we are mostly using the compilers we want and the CXXFLAGS and CFLAGS settings seem to be working. 

However, there is still 700+ instances of calls to the wrong host compiler (bare g++). 

Here is an example. Dirk, can you please take a look?

[700/28621] g++ -MMD -MF v8_snapshot/obj/v8/v8_libbase/bits.o.d -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_TOPCHROME_MD=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_I18N_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_TARGET_ARCH_IA32 -I../../../../../../../home/llozano/chrome_root/src -Iv8_snapshot/gen -I../../../../../../../home/llozano/chrome_root/src/v8 -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -pthread -m32 -msse2 -mfpmath=sse -mmmx -g2 -gsplit-dwarf -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11 -fno-rtti -fno-exceptions -Wno-deprecated -Wno-narrowing -m32 -c ../../../../../../../home/llozano/chrome_root/src/v8/src/base/bits.cc -o v8_snapshot/obj/v8/v8_libbase/bits.o

@dpranke: i'm just adding some clarification for comment 61

@llozano - you've patched in both the chromium CL and the v8 CL?

I am not particularly surprised that chrome_sandbox has $ORIGIN in a component build, because everything gets $ORIGIN by default in a component build.

We don't ship component builds (at least not on non-CrOS platforms) and so we don't care about this or, at least, probably wouldn't have noticed it yet otherwise.

It's possible that we can fix chrome_sandbox to not use $ORIGIN even in a component build (and probably a good idea to do so), but hopefully this isn't blocking anything else you're working on? Maybe file a separate bug for this particular problem?

about the component_build, the situation is a little bit complicated. We are currently using component_build for 32bit boards because we ran out of space for the debug info. We just moved to split debug but we are not totally sure this change is going to stick (need to wait a couple of days). 
Fixing component build may be a good idea because we maybe forced to go back to component builds.. 

I will file a separate issue for this.

about the calls to the wrong compiler (bare g++)

I ONLY applied the following 2 patches:

https://codereview.chromium.org/1969693002/ 
https://codereview.chromium.org/1964303002/

YOu had a couple of patches before that but I was not sure I needed those too. 

What do I need?

 

Neither of those patches is needed (or useful) :).

You need the two listed in comment #55.

sorry, copy paste problem 
the ones I applied are the ones from #55

about #66, after setting cc,ld and ar for v8_snapshot, there are no more uses of the bare g++ compiler!! 

excellent :).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8ad2f49335feaddddbd3f318fc6f4d13eb52760b

commit 8ad2f49335feaddddbd3f318fc6f4d13eb52760b
Author: dpranke <dpranke@chromium.org>
Date: Wed May 18 20:33:04 2016

Rework the way ChromiumOS toolchains will work in GN.

This CL reworks the way ChromiumOS toolchains work in GN, in such a way
that they might actually have all the flags they need for the
ChromiumOS ebuild files to be able to set all of the flags it needs
(though there are still some missing GN build_args).

Specifically, the ebuild will now need to set the following in args.gn:

  host_toolchain = "//build/toolchain/cros:host"
  v8_snapshot_toolchain = "//build/toolchain/cros:v8_snapshot"

in order to support boards other than the amd64-generic build. The
ebuild should actually set these variables all the time; it just
happens that the amd64-generic build will work at the moment without
the variables, but that will not be guaranteed to remain true in the future.

This CL also adds the following optional build args that do pretty
much what you'd expect them to do:

  cros_target_ld, cros_target_extra_cflags, cros_target_extra_cppflags,
  cros_target_extra_cxx_flags, cros_target_extra_ldflags,
  cros_host_ar, cros_host_cc, cros_host_cxx, cros_host_ld,
  cros_host_is_clang, cros_host_extra_cflags, cros_host_extra_cppflags,
  cros_host_extra_cxx_flags, cros_host_extra_ldflags,
  cros_v8_snapshot_ar, cros_v8_snapshot_cc, cros_v8_snapshot_cxx,
  cros_v8_snapshot_ld, cros_v8_snapshot_extra_cflags,
  cros_v8_snapshot_extra_cppflags, cros_v8_snapshot_extra_cxx_flags,
  cros_v8_snapshot_extra_ldflags

This CL should be backwards-compatible with the existing linux desktop
ChromiumOS builds and the amd64-generic simplechrome/ebuild (i.e., it
can be landed and reverted w/o requiring any other changes to be made).
It is a big hammer intended to un-block the ChromiumOS GN migration
while we continue thinking about how to best support ChromiumOS.

R=stevenjb@chromium.org, brettw@chromium.org
BUG= 608596 ,  595653 

Review-Url: https://codereview.chromium.org/1983613002
Cr-Commit-Position: refs/heads/master@{#394534}

[modify] https://crrev.com/8ad2f49335feaddddbd3f318fc6f4d13eb52760b/build/toolchain/cros/BUILD.gn
[modify] https://crrev.com/8ad2f49335feaddddbd3f318fc6f4d13eb52760b/build/toolchain/gcc_toolchain.gni

I did the following:

* Updated chrome to include the changes from https://codereview.chromium.org/1983613002
* Applied the v8 changes from https://codereview.chromium.org/1979883002 as a patch
* Cherry-picked the ebuild changes from https://chromium-review.googlesource.com/#/c/345471/

Then:
* I set BOARD=x86-generic in the chroot and built that.
Everything seemed to build OK.

Then:
* I invoked simple chrome with: 'cros chrome-sdk --board=x86-generic --chroot /usr/local/google/home/stevenjb/Work/chromeos/chroot'
* I regenerated args.gn with: 'gn gen out_x86-generic/Release --args="$GN_ARGS"'
* I started a chrome build

Unfortunately, I immediately got errors.

First I got errors like:

FAILED: host/obj/third_party/icu/icui18n/ucol_res.o 
/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/common/goma+2/gomacc x86_64-pc-linux-gnu-g++ -MMD -MF host/obj/third_party/icu/icui18n/ucol_res.o.d -DU_I18N_IMPLEMENTATION -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_TOPCHROME_MD=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 -DU_CHARSET_IS_UTF8=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= -DU_STATIC_IMPLEMENTATION -I../.. -Ihost/gen -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -Wno-deprecated-declarations -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 -O2 -fno-ident -fdata-sections -ffunction-sections -g2 -gsplit-dwarf -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -Wno-deprecated-declarations -Wno-unused-function -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11 -fno-exceptions -Wno-deprecated -Wno-narrowing -c ../../third_party/icu/source/i18n/ucol_res.cpp -o host/obj/third_party/icu/icui18n/ucol_res.o
GOMA:g++ compiling ../../third_party/icu/source/i18n/ucol_res.cpp:*ERROR*: compiler_proxy:3ms: Failed to find local compiler path
[727/27303] CXX host/obj/third_party/icu/icuuc/resource.o


I disabled goma and got errors like:

FAILED: host/obj/third_party/icu/icuuc/ucnvhz.o 
x86_64-pc-linux-gnu-gcc -MMD -MF host/obj/third_party/icu/icuuc/ucnvhz.o.d -DU_COMMON_IMPLEMENTATION -DU_ICUDATAENTRY_IN_COMMON -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_TOPCHROME_MD=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 -DU_CHARSET_IS_UTF8=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= -DU_STATIC_IMPLEMENTATION -I../.. -Ihost/gen -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 -O2 -fno-ident -fdata-sections -ffunction-sections -g2 -gsplit-dwarf -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -Wno-deprecated-declarations -Wno-unused-function  -c ../../third_party/icu/source/common/ucnvhz.c -o host/obj/third_party/icu/icuuc/ucnvhz.o
/bin/sh: x86_64-pc-linux-gnu-gcc: command not found


IIRC, those failures are probably nacl related?

Also:

In the chroot I run 'which x86_64-pc-linux-gnu-gcc' and get '/usr/bin/x86_64-pc-linux-gnu-gcc'

When I run that outside the chroot I get nothing.

Testing with arm next...

With BOARD=arm-generic in the chroot I get:

FAILED: ../../../../../../../home/stevenjb/chrome_root/src/third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF nacl_bootstrap_arm/obj/native_client/src/trusted/service_runtime/linux/nacl_bootstrap_lib/nacl_bootstrap.o.d -DOS_CHROMEOS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=199506 -D_XOPEN_SOURCE=600 -D_GNU_SOURCE=1 -D__STDC_LIMIT_MACROS=1 -I../../../../../../../home/stevenjb/chrome_root/src -fno-builtin -fno-stack-protector -fno-pic -fno-PIC -fno-pie -fno-PIE --target=arm-linux-gnueabihf -march=armv7-a -mfloat-abi=hard -mthumb -mtune=generic-armv7-a --sysroot=../../../../../../../build/arm-generic -Wall -Werror -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -O2 -fno-ident -fdata-sections -ffunction-sections -g2 -gsplit-dwarf  -c ../../../../../../../home/stevenjb/chrome_root/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c -o nacl_bootstrap_arm/obj/native_client/src/trusted/service_runtime/linux/nacl_bootstrap_lib/nacl_bootstrap.o
/usr/bin/objcopy: Unable to recognise the format of the input file `nacl_bootstrap_arm/obj/native_client/src/trusted/service_runtime/linux/nacl_bootstrap_lib/nacl_bootstrap.o'
[19666/28788] CXX v8_snapshot/obj/v8/v8_base/counters.o
ninja: build stopped: subcommand failed.

about #78... are you sure you are not missing one of the patches? it should not be using this compiler... ../../../../../../../home/stevenjb/chrome_root/src/third_party/llvm-build/Release+Asserts/bin/clang. 
I will try to reproduce tonight.

I applied the patches I mentioned. Am I missing one?

I am getting a similar error with amd64-generic:

 x86_64-pc-linux-gnu-gcc: command not found

about the simple chrome problems, one of the problems we have is that simple chrome is setting PATH for the toolchain path. 
See: https://cs.corp.google.com/chromeos_public/chromite/cli/cros/cros_chrome_sdk.py?sq&q=setuptc+package:%5Echromeos_public$&l=597

How do we fix this? Can GN provide a variable for the toolchain path or should we prepend all the executable names by their path?

What path? I tried this inside the simple chrome shell:

$ which x86_64-pc-linux-gnu-g++

But nothing came up. Also:

$ echo $PATH
/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/common/gsutil_4.18.tar.gz/gsutil:/usr/local/google/home/stevenjb/Work/chrome/src/third_party/chromite/bin:/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/chrome-sdk/tarballs/amd64-generic+8329.0.0+target_toolchain/bin:/usr/local/google/home/stevenjb/goma:/usr/local/google/home/stevenjb/Work/depot_tools:/usr/lib/google-golang/bin:/usr/local/buildtools/java/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

about this problem:

/usr/bin/objcopy: Unable to recognise the format of the input file `nacl_bootstrap_arm/obj/native_client/src/trusted/service_runtime/linux/nacl_bootstrap_lib/nacl_bootstrap.o'

I believe the problem is that the build is using the wrong objcopy. 
I believe GYP was using <toolchain-prefix>-objcopy but I am not totally sure (it seems for Android, at least, it was doing so)

but /usr/bin/objcopy is not the one we should be using.

You should be referring to the executables by their path, rather than relying on PATH to find the right things.

I think I have a solution in progress for #81 and #82. No need  to do anything for PATH. 

For #83, I think we need a solution from GN. This probably includes other tools like readelf and objdump.. we need to figure out what GYP was doing.

Steven's PATH in #82 contains /usr/local/google/home/stevenjb/Work/chrome/src/third_party/chromite/bin:/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/chrome-sdk/tarballs/amd64-generic+8329.0.0+target_toolchain/bin which contains <toolchain-prefix>-objcopy.
So appending the appropriate prefix to objcopy in GN should be sufficient.

Regarding x86_64-pc-linux-gnu-g++, it's put under the directory $SYSROOT, and IIUC GN is already handling it correctly with target_sysroot build arg.

Okay, from poking around in 

https://code.google.com/p/chromium/codesearch#chromium/src/tools/gyp/pylib/gyp/generator/ninja.py

it looks like there are facilities in GYP for reading even more settings from environment variables, including vars for getting NM, NM_host, READELF, and READELF_host.

I can add those easily enough to the cros_* vars. It would be nice if we had some way of figuring out which others we might need.

The only references I see to objcopy are for an android toolchain, and the only references I see to objdump are for a nacl toolchain, so I don't think you'll need to specify those. 

Okay, I've posted a CL for the additional vars here:

https://codereview.chromium.org/2003193002/

As far as I know, there's nothing else for me to do on this bug (at the moment), and this is mostly in stevenjb@ and llozano@'s courts.

I'm going to reassign this to stevenjb@ accordingly. Let me know if I've missed something.

-> llozano@ who I believe understands what we need to do in the ebuild better than I do at this point.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d3de89f668f8e8923a8baa70e1e2b31b5a72fd0

commit 5d3de89f668f8e8923a8baa70e1e2b31b5a72fd0
Author: dpranke <dpranke@chromium.org>
Date: Tue May 24 01:32:24 2016

Add cros_{target,host,v8_snapshot}_{nm,readelf} vars to GN build.

So that the CrOS ebuild builds can customize paths to nm and readelf
as needed.

R=stevenjb@chromium.org, llozano@chromium.org
BUG= 608596 

Review-Url: https://codereview.chromium.org/2003193002
Cr-Commit-Position: refs/heads/master@{#395505}

[modify] https://crrev.com/5d3de89f668f8e8923a8baa70e1e2b31b5a72fd0/build/toolchain/cros/BUILD.gn

dpranke@ 

thanks for adding these but as mentioned in #83, the current problem we have is with objcopy. I don't think chromeos is setting the location for objcopy but I think GYP was deducing the location from the path to the compiler? (I am not sure. I saw some code in there that seemed to deduce the name from the toolchain prefix and then add "-objcopy" at the end.

Sorry, I think I skipped over that too easily before. 

Generally speaking, it doesn't really look like we refer to objcopy directly anywhere in either GYP or GN.

*But*

nacl_helper_bootstrap is particularly a place of dark black magic, and the code for NaCl is quite different between GN and GYP both generally and in this particular case.

I checked w/ mcgrathr@, who observed that one of the reasons the code is the way it is is because it needs to *not* use split-dwarf, and since you're explicitly enabling split-dwarf the code is getting confused. So, in theory we can post a change to force split-dwarf off and things should be fine (it won't try to call objcopy).

I'll post a CL for that and we can see what happens.

The CL for the objcopy thing is https://codereview.chromium.org/2004303005/ ; it will need to roll into Chrome.

turns out you need https://codereview.chromium.org/2011693002/ as well.

I have modified chromite in the following CL

https://chromium-review.googlesource.com/#/c/347024/1

with this, Simple Chrome works for falco (amd64) in combination with the ebuild changes.. 
It also works for Simple chrome and Goma.

I have not tried Daisy with the changes provided by #94 (thanks!)

stevenjb, could you give this a try?

tried the patches at #93 and #94 and I can build daisy in simple chrome. Trying within the chroot now.

daisy build in the chroot also works. So, it seems the problem with objcopy is solved now. 

Excellent! So are we missing anything at this point besides a few potentially not implemented flags?

hard to say.. the builds finish and I have verified a few options look the same but I need to do some more verification. Will try to finish verification by the end of the week.

I just did a clean build in the chroot and in simple chrome with arm/x86/amd64-generic with the following CLs applied:

https://codereview.chromium.org/2004303005/
https://chromium-review.googlesource.com/#/c/347024/
https://chromium-review.googlesource.com/#/c/345471/

All three compiled in both environments!

Let's get these CL's in and get more informational builders up.

I tried a few trybots (one for each architecture) in this way:

$ cbuildbot --remote -g "348012 345471 347024" --chrome_rev=latest_release falco-release daisy-release x86-alex-release

348012 forces the use of GN which is not enabled yet by default.

I get the following error, which I was getting when I began running experiments in my chroot. 
Which patches am I missing?

chromeos-chrome-53.0.2753.0_rc-r1: 0> File build/goma/i686/goma_fetch exists and SHA1 matches. Skipping.
chromeos-chrome-53.0.2753.0_rc-r1: 0> File build/goma/i686/gomacc exists and SHA1 matches. Skipping.
chromeos-chrome-53.0.2753.0_rc-r1: 0> File build/goma/i686/compiler_proxy exists and SHA1 matches. Skipping.
chromeos-chrome-53.0.2753.0_rc-r1: Success!
chromeos-chrome-53.0.2753.0_rc-r1: Downloading 6 files took 0.667259 second(s)
chromeos-chrome-53.0.2753.0_rc-r1: 
chromeos-chrome-53.0.2753.0_rc-r1: ________ running '/usr/bin/python2.7 build/goma/fix_file_modes.py' in '/home/chrome-bot/chrome_root'
chromeos-chrome-53.0.2753.0_rc-r1: gn.py: Could not find gn executable at: /home/chrome-bot/chrome_root/buildtools/linux64/gn

It looks like something is invoking depot_tools/gn.py, rather than invoking src/buildtools/linux64/gn directly. 

The former is a convenience wrapper that tries to find gn.py in a checkout, but it's known to be buggy (there's a bug on file but I can't find it at the moment).

I thought we had fixed this in the ebuild, though ...

Is gn.py useful? It seems to just cause more trouble and confusion?

It appears to be somewhat useful for devs, since it keeps you from having to add another directory to your path. I don't think bots should use it, at least not as it is currently implemented.

Ah, found the bug: crbug.com/588794 .

I will modify the ebuild to call gn directly. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5e7fefdeec1e657acf93ba3f7475729797508ca9

commit 5e7fefdeec1e657acf93ba3f7475729797508ca9
Author: nacl-deps-roller <nacl-deps-roller@chromium.org>
Date: Tue May 31 19:29:33 2016

Roll src/native_client/ a5ccf8917..f9308087f (1 commit).

https://chromium.googlesource.com/native_client/src/native_client.git/+log/a5ccf89172d4..f9308087f764

$ git log a5ccf8917..f9308087f --date=short --no-merges --format='%ad %ae %s'
2016-05-27 dpranke Force split-dwarf off for nacl_helper_bootstrap.

BUG= 608596 

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_dbg_32_ng,linux_nacl_sdk_build
TBR=mseaborn@chromium.org

Review-Url: https://codereview.chromium.org/2020783002
Cr-Commit-Position: refs/heads/master@{#396894}

[modify] https://crrev.com/5e7fefdeec1e657acf93ba3f7475729797508ca9/DEPS

testing with the change to use gn directly is going much better.
However, daisy failed because the fix for objcopy has not made it into chromeos. 
Chrome PFQ has not been succesful since the 26th. Change went in on the 27th.

I think the native_client change only got finally rolled into Chromium a little while ago, in #396894:

https://codereview.chromium.org/2020783002

so if you can roll Chromium into the PFQ maybe it'll work now?

falco builds ok with the chroot. Unfortunatelly this board is not exercising simple chrome (so ignore the green step there)

https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/release/builds/4057

same with alex:

https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/release/builds/4056

retrying with different boards to get simple chrome tested.

ok, got the simple chrome tested. it passes.
also, the problem with objcopy is now tested. 
I will finish code reviews for this and commit. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ccf4537e0c492ff2c83b8f4cdfee101e052977d0

commit ccf4537e0c492ff2c83b8f4cdfee101e052977d0
Author: Luis Lozano <llozano@chromium.org>
Date: Tue May 17 18:44:11 2016

Use new GN variables to pass several compiler settings.

Use new GN variables to set things like:

{C,CXX,CPP,LD}FLAGS
{C,CXX,CPP,LD}FLAGS_host
{CC,CXX,AR}_host

Also, change the way to find the gn executable.

BUG= chromium:608596 
TEST=Tested release buildbots for each architecture
     with simple chrome validation and hwtests.

Change-Id: I4224394710afb889195da65802964d08129d8d49
Reviewed-on: https://chromium-review.googlesource.com/345471
Commit-Ready: Luis Lozano <llozano@chromium.org>
Tested-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>

[modify] https://crrev.com/ccf4537e0c492ff2c83b8f4cdfee101e052977d0/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

Just build arm-generic locally with ToT and the chromite CL: https://chromium-review.googlesource.com/#/c/347024/

Everything built fine but I got a bunch of the following warnings building v8:

warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/7b5c1d36149b3b37402cdb4531a6ffacfec339d4

commit 7b5c1d36149b3b37402cdb4531a6ffacfec339d4
Author: Luis Lozano <llozano@chromium.org>
Date: Tue May 24 23:17:45 2016

chromite: Fix some issues with the GN support.

Fixed some issues with GN support after changes in the
chrome ebuild to support GN within the chroot.

BUG= chromium:608596 
TEST=simple chrome works for Falco with and without Goma.
     Also tested for daisy.
     run_tests.

Change-Id: I77deefbf3fa21f4054c4b05386574b61fe0bcc30
Reviewed-on: https://chromium-review.googlesource.com/347024
Commit-Ready: Steven Bennetts <stevenjb@chromium.org>
Tested-by: Steven Bennetts <stevenjb@chromium.org>
Tested-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/7b5c1d36149b3b37402cdb4531a6ffacfec339d4/cli/cros/cros_chrome_sdk.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/9a20cdbe118245b12b23acb1ad454ce8acdb9337

commit 9a20cdbe118245b12b23acb1ad454ce8acdb9337
Author: Luis Lozano <llozano@chromium.org>
Date: Thu Jun 16 00:48:55 2016

GN Changes: make sure that for SimpleChrome we use the bundled binutils.

We should make sure we are not using the system binutils. Instead
use the binutils that comes bundled within Chrome.

BUG= chromium:608596 
TEST=trybots for 4 lead boards that test simple chrome.

Change-Id: Ic9a3255d725f3009931f9d0f745b3bb290a544c0
Reviewed-on: https://chromium-review.googlesource.com/353027
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Commit-Queue: Luis Lozano <llozano@chromium.org>
Tested-by: Luis Lozano <llozano@chromium.org>

[modify] https://crrev.com/9a20cdbe118245b12b23acb1ad454ce8acdb9337/cli/cros/cros_chrome_sdk.py

The warning is tracked separately:  issue 618346 

Is this fixed? If not is it blocking  issue 433082 ?

I think remaining issues are reported elsewhere.

bulk verified