All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Perez de Castro <aperez@igalia.com>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2018-01-21
Date: Thu, 25 Jan 2018 21:03:13 +0000	[thread overview]
Message-ID: <20180125210313.GD14023@momiji> (raw)
In-Reply-To: <87fu6vn0ud.fsf@dell.be.48ers.dk>

Hi there,

A quick update regarding this WebKitGTK+ build failure...

On Wed, 24 Jan 2018 08:59:54 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:
> >>>>> "Adrian" == Adrian Perez de Castro <aperez@igalia.com> writes:
> 
>  > Hi,
>  > On Mon, 22 Jan 2018 08:00:14 +0100 (CET), Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 
>  >> x86_64 | webkitgtk-2.18.5 | NOK |
>  >> http://autobuild.buildroot.net/results/57b77520d3a3fcfa683406e223771d0ccf8733df
>  >> |
> 
>  > The configuration used for this build has an EGL provider but both OpenGL and
>  > OpenGL ES are disabled:
> 
>  >  - BR2_PACKAGE_HAS_LIBEGL is chosen.
>  >  - Both BR2_PACKAGE_HAS_LIBGL and BR2_PACKAGE_HAS_LIBGLES are undefined.
> 
>  > It seems to me that the CMake build files for WebKit should disable all the
>  > OpenGL support if EGL is found but a GL/GLES implementation is not found.
>  > I have filed a bug upstream to look into that:
> 
>  >   https://bugs.webkit.org/show_bug.cgi?id=181986
> 
> Sounds sensible, yes.
> 
>  > In the meantime, I'll make a patch for checking in the Buildroot package
>  > whether an OpenGL(ES) implementation is being built, and if not pass the
>  > needed build flags to CMake in order to disable using OpenGL(ES) even if
>  > EGL is present.
> 
> Thanks!

It turns out that Buildroot it already doing the correct thing, and it's
passing ?-DENABLE_OPENGL=OFF? when there is only an EGL provider but no
GL/GLES provider. As soon as I have a fix for the WebKit CMake files I can
send a patch to add it to Buildroot. In the meantime I am afraid that trying
to build WebKitGTK+ when the target only has EGL but no GL/GLES will be
broken ? this is not expected to affect real-world uses, though; I imagine
whenever EGL is chosen there will be also GL/GLES as well.

I have also posted a set of two patches to get WebKitGTK+ updated to 2.18.6;
note that this build issue is still present in that new release.

Cheers,

--
 Adri?n ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180125/4b723fe1/attachment.asc>

      reply	other threads:[~2018-01-25 21:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22  7:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-01-21 Thomas Petazzoni
2018-01-23 15:21 ` Adrian Perez de Castro
2018-01-24  7:59   ` Peter Korsgaard
2018-01-25 21:03     ` Adrian Perez de Castro [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180125210313.GD14023@momiji \
    --to=aperez@igalia.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.