I don't think minnie has X11 (needed for !ozone). Only nyan does according to ihf@.

Building with nyan I get:

../../third_party/angle/src/libANGLE/renderer/gl/glx/FunctionsGLX.cpp:15:20: fatal error: GL/glx.h: No such file or directory
 #include <GL/glx.h>
                    ^
compilation terminated.


args.gn:

 $ cat out_$SDK_BOARD/Release/args.gn
is_asan = false
target_cpu = "arm"
enable_nacl = true
use_goma = true
cros_target_ar = "armv7a-cros-linux-gnueabi-ar"
arm_float_abi = "hard"
is_component_build = true
use_v4l2_codec = true
cros_target_cxx = "armv7a-cros-linux-gnueabi-g++ -B/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/chrome-sdk/tarballs/nyan+8276.0.0+target_toolchain/usr/x86_64-pc-linux-gnu/armv7a-cros-linux-gnueabi/binutils-bin/2.25.51-gold"
is_clang = false
goma_dir = "/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/common/goma+2"
cros_target_cc = "armv7a-cros-linux-gnueabi-gcc -B/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/chrome-sdk/tarballs/nyan+8276.0.0+target_toolchain/usr/x86_64-pc-linux-gnu/armv7a-cros-linux-gnueabi/binutils-bin/2.25.51-gold"
target_sysroot = "/usr/local/google/home/stevenjb/Work/chrome/.cros_cache/chrome-sdk/tarballs/nyan+8276.0.0+sysroot_chromeos-base_chromeos-chrome.tar.xz"
system_libdir = "lib"
use_evdev_gestures = false
use_cras = true
use_debug_fission = true
is_debug = false
use_v4lplugin = false
use_ozone = false
clang_use_chrome_plugins = false
enable_remoting = true
arm_use_neon = true
linux_use_bundled_binutils = false
use_system_harfbuzz = true
use_xkbcommon = false
icu_use_data_file = true
symbol_level = 2
target_os = "chromeos"

(Note: I did not edit the args.gn above)

That looks like it's picking up GLX instead of EGL. I'm not sure I remember how that is done. Are there GYP flags for that config that were not ported to GN?

Actually, no, we always require GLX to be there with X11, that's true in gyp as well.

This part is in ANGLE. It looks like angle_enable_gl is always set to true on linux in gn, whereas in gyp it's only set on !chromeos - my guess is that it's the difference.

Frank is working on our ChromeOS port.

I have a potential fix here: https://chromium-review.googlesource.com/#/c/342740/

I have confirmed that with that addressed, building the following succeeds:

chrome chrome_sandbox nacl_helper chromiumos_preflight

target_os = "chromeos" and use_ozone = false should result in ANGLE GLX backend being compiled.
This config is intended for Linux desktop chromeos=1 build.

For real chromeos you should have use_ozone = true, except for nyan.
I don't think we want to make any change for nyan, unless it blocks somebody - we'd prefer to wait for nyan to support use_ozone.

And, we need to modify our GN files to support use_ozone = true, as we've only made the GYP change so far.

Bottom line - I think it's expected that use_ozone = false will fail to compile on ChromeOS.

This issue is specifically for nyan at this point. Updated the description.

The current behavior may be "expected" but it is surprising.

We should prioritize fixing nyan (and any active configuration) for GN. I do not particularly care how, but please prioritize the effort.

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

commit 72ae51fd50edfa7120c291a556da1d7f7f2046f7
Author: stevenjb <stevenjb@chromium.org>
Date: Fri May 06 17:54:00 2016

Roll src/third_party/angle/ bbd663a2d..a314b61c1 (7 commits).

BUG= 609250 
TBR=jmadill@chromium.org

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.linux:linux_optional_gpu_tests_rel

https://chromium.googlesource.com/angle/angle.git/+log/bbd663a2d36e..a314b61c16be

$ git log bbd663a2d..a314b61c1 --date=short --no-merges --format='%ad %ae %s'
2016-03-10 oetuaho@nvidia.com Determine D3D texture storage size with correct base level
2016-05-05 stevenjb@chromium.org Disable angle_enable_gl on chromeos
2016-05-04 jbauman@chromium.org Fix eglStreamConsumerAcquireKHR
2016-04-26 jmadill@chromium.org Pass ContextImpl to Framebuffer methods instead of ContextState.
2016-05-03 jmadill@chromium.org Add a ContextImpl class.
2016-04-29 oetuaho@nvidia.com Add missing errors specified by OES_EGL_image_external
2016-04-28 jmadill@chromium.org Add script for updating Canary ANGLE DLLs.

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

[modify] https://crrev.com/72ae51fd50edfa7120c291a556da1d7f7f2046f7/DEPS

Closing this issue. The angle issue remains open, it can be resolved or used to track a better fix.

Thanks for fixing this, Steven!
Regarding the expected behavior - I got a bit confused between the current ANGLE usage in Chrome, and our future plans to expand on it.
The current usage should work everywhere, of course.
For the future plans, we'll wait for nyan to support use_ozone=true before enabling angle_enable_gl on it.

@ynovikov:

I don't think I understand the implications of "we'll wait for nyan to support use_ozone=true before enabling angle_enable_gl on it".

Is there any part of that statement that might mean that we're blocked on something before we can build nyan w/ GN? I'm hopefully interpreting that as, we can build nyan w/ use_ozone=false w/ GN, we just won't get angle+GL support?

Your hopeful interpretation is correct.

Bulk verified

bulk verified