Hmm.

----

#elif defined(__unix__)

/* X11 (tentative)  */
#include <X11/Xlib.h>
#include <X11/Xutil.h>

typedef Display *EGLNativeDisplayType;
typedef Pixmap   EGLNativePixmapType;
typedef Window   EGLNativeWindowType;

#else

----

What's the status of glbench? Building X11 code seems... not that useful.

That seems to be a build fluke where glbench is configured wrong on the first compile. The second attempt builds (without X11).

WARNING: The following packages failed once or more,
but succeeded upon retry. This might indicate incorrect
dependencies.
  chromeos-base/autotest-deps-glbench-0.0.1-r7576
@@@STEP_WARNINGS@@@

Building X11 in this case makes sense, the reason is that one of the egl headers (eglplatform.h) depends on Xlib.h. We cannot really change this header because it is written by khronos, and we import new updates from time to time. So we have to satisfy the dependency. Also this isn't directly related to glbench, glbench just happens to pull opengles-headers.

The dependency chain is as follows:
glbench (which needs opengles headers) -> opengles-headers (which as explained before needs Xlib.h for reasons we don't control) -> libX11 (including the Xlib.h header)

Now if you look at the build log, the first time it builds, opengles-headers is built before glbench, and that is correct. However libX11 is not built before opengles-headers despite the dependency being present in the ebuild. That is the part which is incorrect.

I tried locally without a parallel build, and opengles-headers properly pulls in libX11 so the dependency in the opengles-headers ebuild is properly expressed. However something else is blocking it and I am not sure what. It could be the parallel build stuff.

It'd be nice if we didn't build libX11. Can we find a way to do that, like changing some ebuilds to not build EGL?

@4: no matter what we do, we will always require EGL. EGL is the window system integration layer for OpenGLES, and Chrome requires it. We could conceivably replace the full libX11 build with a package that only installs the X11 headers to cut down on dependencies and build time.

However we should probably figure out why dependencies are not working first, before changing anything more :)

the problem i think is the binary aspects.  those builds used a binpkg of opengles-headers which means DEPEND can be correctly ignored.

i think we need to add libX11 to opengles-headers' RDEPEND with a comment explaining why.  it shouldn't cause a problem in the end as nothing lists opengles-headers in RDEPEND ...

splitting libX11 into headers/libs wouldn't help this particular issue.

Just an update on this bug: This exception goes away from the information builders one by one. Now all the informational builders don't have this exception on their BuildPackage stage anymore. Not sure if we still need to keep this issue open.

@6: ok, we'll add it to RDEPEND then.

Side note: splitting libX11 into headers/libs is a tangential discussion which would allow us to cut down some build dependencies. There are 66 packages which get pulled by libX11, so reducing the dependencies here could be interesting.

considering how much upstream X.org has split headers into (xxx)proto packages, doesn't *seem* like it'd be too hard for this either, but maybe it would ;).  if X.org doesn't split, then it's extremely unlikely that Gentoo would.  but at this point in the CrOS no-X cycle, i don't think doing it ourselves in chromiumos-overlay would be too onerous.

the change https://chromium-review.googlesource.com/#/c/435483/ has landed to fix this, but the bug hasn't auto updated.

Closing. Please reopen it if its not fixed. Thanks!