[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Antoine Tenart]

Hi all,

I've run into a build failure while compiling an image, when building
QT5. I made some build tests to narrow down the issue and found the
configuration leading to this: when compiling an image with both
BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
build fails with the following error:

http://code.bulix.org/qxj1bn-92391?raw

I understand this configuration can't work, but as this leads to a
build issue we might need to think about a solution. We could disallow
such a configuration tuple, or fix the build.

Any idea?

Thanks,

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160304/3840cc84/attachment.asc>

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Gary Bisson]

Antoine, All,

Adding J?r?me in cc since he's the one behind the x11/fb selection as
well as qt5 graphics support for i.MX.

On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
<antoine.tenart@free-electrons.com> wrote:
> Hi all,
>
> I've run into a build failure while compiling an image, when building
> QT5. I made some build tests to narrow down the issue and found the
> configuration leading to this: when compiling an image with both
> BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
> build fails with the following error:
>
> http://code.bulix.org/qxj1bn-92391?raw

Indeed that's a problem. It looks like the question has been raised in
the Yocto community not so long ago:
https://github.com/Freescale/meta-fsl-arm/commit/da8f520a

It looks like their patch is to define EGL_API_FB although X11 is in
use. I imagine we could do the same using J?r?me's approach but
depending on EGLFS define:
https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu-viv/imx-gpu-viv.mk#n55

However I guess that would only fix the build but would cause issues
at runtime which might be confusing for users.

> I understand this configuration can't work, but as this leads to a
> build issue we might need to think about a solution. We could disallow
> such a configuration tuple, or fix the build.
>
> Any idea?

I'm afraid forcing the imx-gpu-viv package output format depending on
qt5 graphical back end would bring many "recursive dependency" issues.

J?r?me, what are your thoughts?

Thanks,
Gary

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Thomas Petazzoni]

Gary,

On Fri, 4 Mar 2016 12:02:31 +0100, Gary Bisson wrote:

> > I understand this configuration can't work, but as this leads to a
> > build issue we might need to think about a solution. We could disallow
> > such a configuration tuple, or fix the build.
> >
> > Any idea?
> 
> I'm afraid forcing the imx-gpu-viv package output format depending on
> qt5 graphical back end would bring many "recursive dependency" issues.

I don't see why it would create recursive dependency issues.

However, it would violate the principle of virtual packages, since Qt5
is not supposed to have some dependencies that are specific to certain
OpenGL implementations. It should normally just use dependencies on the
OpenGL ES / EGL packages, and nothing else.

However, we could probably add some exceptions to this rule. Or rework
the virtual package logic so that consumers of OpenGL can now whether
the FB or X11 support is available.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Gary Bisson]

Thomas, All,

On Fri, Mar 4, 2016 at 12:13 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Gary,
>
> On Fri, 4 Mar 2016 12:02:31 +0100, Gary Bisson wrote:
>
>> > I understand this configuration can't work, but as this leads to a
>> > build issue we might need to think about a solution. We could disallow
>> > such a configuration tuple, or fix the build.
>> >
>> > Any idea?
>>
>> I'm afraid forcing the imx-gpu-viv package output format depending on
>> qt5 graphical back end would bring many "recursive dependency" issues.
>
> I don't see why it would create recursive dependency issues.

Well my thought process was that it was kind of forbidden to modify
the qtbase package for a i.MX-specific corner case.

So I tried to force it in imx-gpu-viv to use fb depending on
BR2_PACKAGE_QT5BASE_EGLFS but it only brought those recursive issues.

> However, it would violate the principle of virtual packages, since Qt5
> is not supposed to have some dependencies that are specific to certain
> OpenGL implementations. It should normally just use dependencies on the
> OpenGL ES / EGL packages, and nothing else.
>
> However, we could probably add some exceptions to this rule. Or rework
> the virtual package logic so that consumers of OpenGL can now whether
> the FB or X11 support is available.

Well if we are allowed to modify qtbase I guess it would be way
easier. Would something like this be acceptable?
index 64a7f65..aa54b3e 100644
--- a/package/qt5/qt5base/Config.in
+++ b/package/qt5/qt5base/Config.in
@@ -201,10 +201,14 @@ config BR2_PACKAGE_QT5BASE_EGLFS
        select BR2_PACKAGE_QT5BASE_OPENGL
        depends on BR2_PACKAGE_HAS_LIBEGL
        depends on BR2_PACKAGE_QT5_GL_AVAILABLE
+       depends on !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11

 comment "eglfs backend available if OpenGL and EGL are enabled"
        depends on !BR2_PACKAGE_HAS_LIBEGL || !BR2_PACKAGE_QT5_GL_AVAILABLE

+comment "eglfs backend not available for X11 version of i.MX 3D libraries"
+       depends on BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
+
 config BR2_PACKAGE_QT5BASE_DEFAULT_QPA
        string "Default graphical platform"
        help

Regards,
Gary

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Thomas Petazzoni]

Hello,

On Fri, 4 Mar 2016 14:10:58 +0100, Gary Bisson wrote:

> Well my thought process was that it was kind of forbidden to modify
> the qtbase package for a i.MX-specific corner case.
> 
> So I tried to force it in imx-gpu-viv to use fb depending on
> BR2_PACKAGE_QT5BASE_EGLFS but it only brought those recursive issues.

You indeed can't do this, as it creates a circular dependency.

> Well if we are allowed to modify qtbase I guess it would be way
> easier. Would something like this be acceptable?
> index 64a7f65..aa54b3e 100644
> --- a/package/qt5/qt5base/Config.in
> +++ b/package/qt5/qt5base/Config.in
> @@ -201,10 +201,14 @@ config BR2_PACKAGE_QT5BASE_EGLFS
>         select BR2_PACKAGE_QT5BASE_OPENGL
>         depends on BR2_PACKAGE_HAS_LIBEGL
>         depends on BR2_PACKAGE_QT5_GL_AVAILABLE
> +       depends on !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
> 
>  comment "eglfs backend available if OpenGL and EGL are enabled"
>         depends on !BR2_PACKAGE_HAS_LIBEGL || !BR2_PACKAGE_QT5_GL_AVAILABLE
> 
> +comment "eglfs backend not available for X11 version of i.MX 3D libraries"
> +       depends on BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
> +

No this is not good, because there are other OpenGL implementations
than imx-gpu-viv. So at the very least, you would need something like
the below. I also believe it makes more sense to use positive
condition, i.e express a dependency on the FB output, rather than a
dependency on not having the X11 output.

	# If the imx-gpu-viv implementation is used, we need its FB variant
	depends on !BR2_PACKAGE_IMX_GPU_VIV || BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB

comment "eglfs backend needs the FB output of i.MX GPU libraries"
	depends on BR2_PACKAGE_IMX_GPU_VIV && !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Gary Bisson]

Thomas, All,

On Fri, Mar 4, 2016 at 2:19 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 4 Mar 2016 14:10:58 +0100, Gary Bisson wrote:
>
>> Well my thought process was that it was kind of forbidden to modify
>> the qtbase package for a i.MX-specific corner case.
>>
>> So I tried to force it in imx-gpu-viv to use fb depending on
>> BR2_PACKAGE_QT5BASE_EGLFS but it only brought those recursive issues.
>
> You indeed can't do this, as it creates a circular dependency.
>
>> Well if we are allowed to modify qtbase I guess it would be way
>> easier. Would something like this be acceptable?
>> index 64a7f65..aa54b3e 100644
>> --- a/package/qt5/qt5base/Config.in
>> +++ b/package/qt5/qt5base/Config.in
>> @@ -201,10 +201,14 @@ config BR2_PACKAGE_QT5BASE_EGLFS
>>         select BR2_PACKAGE_QT5BASE_OPENGL
>>         depends on BR2_PACKAGE_HAS_LIBEGL
>>         depends on BR2_PACKAGE_QT5_GL_AVAILABLE
>> +       depends on !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
>>
>>  comment "eglfs backend available if OpenGL and EGL are enabled"
>>         depends on !BR2_PACKAGE_HAS_LIBEGL || !BR2_PACKAGE_QT5_GL_AVAILABLE
>>
>> +comment "eglfs backend not available for X11 version of i.MX 3D libraries"
>> +       depends on BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
>> +
>
> No this is not good, because there are other OpenGL implementations
> than imx-gpu-viv. So at the very least, you would need something like
> the below. I also believe it makes more sense to use positive
> condition, i.e express a dependency on the FB output, rather than a
> dependency on not having the X11 output.
>
>         # If the imx-gpu-viv implementation is used, we need its FB variant
>         depends on !BR2_PACKAGE_IMX_GPU_VIV || BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB
>
> comment "eglfs backend needs the FB output of i.MX GPU libraries"
>         depends on BR2_PACKAGE_IMX_GPU_VIV && !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB

I agree using the positive condition is better. However I'm not sure
to understand why !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 wouldn't work
with other OpenGL implementations. This variable is only set when
selecting the vivante package + x11 output. So for any other
implementation it wouldn't be set. It's just out of curiosity that I'd
like to understand the difference.

Regards,
Gary

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Thomas Petazzoni]

Gary,

On Fri, 4 Mar 2016 14:35:55 +0100, Gary Bisson wrote:

> >> Well if we are allowed to modify qtbase I guess it would be way
> >> easier. Would something like this be acceptable?
> >> index 64a7f65..aa54b3e 100644
> >> --- a/package/qt5/qt5base/Config.in
> >> +++ b/package/qt5/qt5base/Config.in
> >> @@ -201,10 +201,14 @@ config BR2_PACKAGE_QT5BASE_EGLFS
> >>         select BR2_PACKAGE_QT5BASE_OPENGL
> >>         depends on BR2_PACKAGE_HAS_LIBEGL
> >>         depends on BR2_PACKAGE_QT5_GL_AVAILABLE
> >> +       depends on !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
> >>
> >>  comment "eglfs backend available if OpenGL and EGL are enabled"
> >>         depends on !BR2_PACKAGE_HAS_LIBEGL || !BR2_PACKAGE_QT5_GL_AVAILABLE
> >>
> >> +comment "eglfs backend not available for X11 version of i.MX 3D libraries"
> >> +       depends on BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11
> >> +
> >
> > No this is not good, because there are other OpenGL implementations
> > than imx-gpu-viv. So at the very least, you would need something like
> > the below. I also believe it makes more sense to use positive
> > condition, i.e express a dependency on the FB output, rather than a
> > dependency on not having the X11 output.
> >
> >         # If the imx-gpu-viv implementation is used, we need its FB variant
> >         depends on !BR2_PACKAGE_IMX_GPU_VIV || BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB
> >
> > comment "eglfs backend needs the FB output of i.MX GPU libraries"
> >         depends on BR2_PACKAGE_IMX_GPU_VIV && !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_FB
> 
> I agree using the positive condition is better. However I'm not sure
> to understand why !BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 wouldn't work
> with other OpenGL implementations. This variable is only set when
> selecting the vivante package + x11 output. So for any other
> implementation it wouldn't be set. It's just out of curiosity that I'd
> like to understand the difference.

Aah, yes, you're right. Your version is functionally equivalent to mine.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Antoine Tenart]

On Fri, Mar 04, 2016 at 12:02:31PM +0100, Gary Bisson wrote:
> On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
> <antoine.tenart@free-electrons.com> wrote:
> >
> > I've run into a build failure while compiling an image, when building
> > QT5. I made some build tests to narrow down the issue and found the
> > configuration leading to this: when compiling an image with both
> > BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
> > build fails with the following error:
> >
> > http://code.bulix.org/qxj1bn-92391?raw
> 
> Indeed that's a problem. It looks like the question has been raised in
> the Yocto community not so long ago:
> https://github.com/Freescale/meta-fsl-arm/commit/da8f520a
> 
> It looks like their patch is to define EGL_API_FB although X11 is in
> use. I imagine we could do the same using J?r?me's approach but
> depending on EGLFS define:
> https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu-viv/imx-gpu-viv.mk#n55
> 
> However I guess that would only fix the build but would cause issues
> at runtime which might be confusing for users.

It's not possible to ensure every possible configuration will be
working. A simple example would be to compile a bootloader for a board A
and a kernel for a completely different board B.

Here, the configuration leading to this build error does not make sense.
So if we only fix the build, leading to an unusable image I guess that
would be OK. (And fixing the build is important, for build bots for
example).

Another solution, fixing both the build and the generated image could be
to define other virtual packages for the EGL implementation. We could
end up with the following for imx-gpu-viv:

	select BR2_PACKAGE_HAS_LIBEGL
	select BR2_PACKAGE_HAS_LIBEGL_X11

and

	select BR2_PACKAGE_HAS_LIBEGL
	select BR2_PACKAGE_HAS_LIBEGL_FB

This would still allow packages to depend on BR2_PACKAGE_HAS_LIBEGL,
while allowing a fine dependency check given the EGL output.

Exact implementation of these new virtual packages can be debated if
the solution is approved. (Like do we make them select
BR2_PACKAGE_HAS_LIBEGL or do we still select it manually in all the
packages providing an EGL implementation).

The drawback is we need to patch all EGL implementations, to fix a
build issue introduced by only one of them.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160304/032c60cb/attachment.asc>

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Gary Bisson]

Antoine, All,

On Fri, Mar 4, 2016 at 2:50 PM, Antoine Tenart
<antoine.tenart@free-electrons.com> wrote:
> On Fri, Mar 04, 2016 at 12:02:31PM +0100, Gary Bisson wrote:
>> On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
>> <antoine.tenart@free-electrons.com> wrote:
>> >
>> > I've run into a build failure while compiling an image, when building
>> > QT5. I made some build tests to narrow down the issue and found the
>> > configuration leading to this: when compiling an image with both
>> > BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
>> > build fails with the following error:
>> >
>> > http://code.bulix.org/qxj1bn-92391?raw
>>
>> Indeed that's a problem. It looks like the question has been raised in
>> the Yocto community not so long ago:
>> https://github.com/Freescale/meta-fsl-arm/commit/da8f520a
>>
>> It looks like their patch is to define EGL_API_FB although X11 is in
>> use. I imagine we could do the same using J?r?me's approach but
>> depending on EGLFS define:
>> https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu-viv/imx-gpu-viv.mk#n55
>>
>> However I guess that would only fix the build but would cause issues
>> at runtime which might be confusing for users.
>
> It's not possible to ensure every possible configuration will be
> working. A simple example would be to compile a bootloader for a board A
> and a kernel for a completely different board B.
>
> Here, the configuration leading to this build error does not make sense.
> So if we only fix the build, leading to an unusable image I guess that
> would be OK. (And fixing the build is important, for build bots for
> example).

I agree but here Thomas gave a green light on modifying the qtbase
package directly for this corner case which fixes both the build and
possible runtime issues.

BTW, who's making/sending the patch now?

Regards,
Gary

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Jérôme Pouiller]

Hello Gary,

On Friday 04 March 2016 12:02:31 Gary Bisson wrote:
> Antoine, All,
> 
> Adding J?r?me in cc since he's the one behind the x11/fb selection as
> well as qt5 graphics support for i.MX.
> 
> On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
> 
> <antoine.tenart@free-electrons.com> wrote:
> > Hi all,
> > 
> > I've run into a build failure while compiling an image, when
> > building
> > QT5. I made some build tests to narrow down the issue and found the
> > configuration leading to this: when compiling an image with both
> > BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
> > build fails with the following error:
> > 
> > http://code.bulix.org/qxj1bn-92391?raw
> 
> Indeed that's a problem. It looks like the question has been raised in
> the Yocto community not so long ago:
> https://github.com/Freescale/meta-fsl-arm/commit/da8f520a
> 
> It looks like their patch is to define EGL_API_FB although X11 is in
> use. I imagine we could do the same using J?r?me's approach but
> depending on EGLFS define:
> https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu
> -viv/imx-gpu-viv.mk#n55
> 
> However I guess that would only fix the build but would cause issues
> at runtime which might be confusing for users.
> 
> > I understand this configuration can't work, but as this leads to a
> > build issue we might need to think about a solution. We could
> > disallow such a configuration tuple, or fix the build.
> > 
> > Any idea?
> 
> I'm afraid forcing the imx-gpu-viv package output format depending on
> qt5 graphical back end would bring many "recursive dependency" issues.
> 
> J?r?me, what are your thoughts?

An alternative solution would be to rename  EGL_API_FB into 
MESA_EGL_NO_X11_HEADERS. Indeed, since this variable is used by Mesa 
headers, it is the de facto standard way to disable X11 headers 
inclusion.
As far as I remember, Qt5 correctly set MESA_EGL_NO_X11_HEADERS when it 
compile EGLFS.

IMHO, it is the most elegant way to solve compilation problem. It would 
allow to compile Qt5 with both X11 and EGLFS enabled (sure, only one 
backend will work at runtime). However, I afraid to do such deep change 
in Vivante headers.


BR,

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Antoine Tenart]

On Fri, Mar 04, 2016 at 02:58:37PM +0100, Gary Bisson wrote:
> On Fri, Mar 4, 2016 at 2:50 PM, Antoine Tenart
> <antoine.tenart@free-electrons.com> wrote:
> > On Fri, Mar 04, 2016 at 12:02:31PM +0100, Gary Bisson wrote:
> >> On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
> >> <antoine.tenart@free-electrons.com> wrote:
> >> >
> >> > I've run into a build failure while compiling an image, when building
> >> > QT5. I made some build tests to narrow down the issue and found the
> >> > configuration leading to this: when compiling an image with both
> >> > BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
> >> > build fails with the following error:
> >> >
> >> > http://code.bulix.org/qxj1bn-92391?raw
> >>
> >> Indeed that's a problem. It looks like the question has been raised in
> >> the Yocto community not so long ago:
> >> https://github.com/Freescale/meta-fsl-arm/commit/da8f520a
> >>
> >> It looks like their patch is to define EGL_API_FB although X11 is in
> >> use. I imagine we could do the same using J?r?me's approach but
> >> depending on EGLFS define:
> >> https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu-viv/imx-gpu-viv.mk#n55
> >>
> >> However I guess that would only fix the build but would cause issues
> >> at runtime which might be confusing for users.
> >
> > It's not possible to ensure every possible configuration will be
> > working. A simple example would be to compile a bootloader for a board A
> > and a kernel for a completely different board B.
> >
> > Here, the configuration leading to this build error does not make sense.
> > So if we only fix the build, leading to an unusable image I guess that
> > would be OK. (And fixing the build is important, for build bots for
> > example).
> 
> I agree but here Thomas gave a green light on modifying the qtbase
> package directly for this corner case which fixes both the build and
> possible runtime issues.

Reading Thomas' mail, I don't think he gave a green light on this.

So we still have to choose a solution to fix this (which may be the one
directly modifying the qt5base package, but we first need to agree on
the solution).

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160307/c534fe30/attachment.asc>

[Buildroot] Build failure with Vivante and QT5 w/ eglfs

[Gary Bisson]

Antoine, All,

On Mon, Mar 7, 2016 at 11:18 AM, Antoine Tenart
<antoine.tenart@free-electrons.com> wrote:
>
> On Fri, Mar 04, 2016 at 02:58:37PM +0100, Gary Bisson wrote:
> > On Fri, Mar 4, 2016 at 2:50 PM, Antoine Tenart
> > <antoine.tenart@free-electrons.com> wrote:
> > > On Fri, Mar 04, 2016 at 12:02:31PM +0100, Gary Bisson wrote:
> > >> On Fri, Mar 4, 2016 at 10:55 AM, Antoine Tenart
> > >> <antoine.tenart@free-electrons.com> wrote:
> > >> >
> > >> > I've run into a build failure while compiling an image, when building
> > >> > QT5. I made some build tests to narrow down the issue and found the
> > >> > configuration leading to this: when compiling an image with both
> > >> > BR2_PACKAGE_QT5BASE_EGLFS and BR2_PACKAGE_IMX_GPU_VIV_OUTPUT_X11 the
> > >> > build fails with the following error:
> > >> >
> > >> > http://code.bulix.org/qxj1bn-92391?raw
> > >>
> > >> Indeed that's a problem. It looks like the question has been raised in
> > >> the Yocto community not so long ago:
> > >> https://github.com/Freescale/meta-fsl-arm/commit/da8f520a
> > >>
> > >> It looks like their patch is to define EGL_API_FB although X11 is in
> > >> use. I imagine we could do the same using J?r?me's approach but
> > >> depending on EGLFS define:
> > >> https://git.buildroot.net/buildroot/tree/package/freescale-imx/imx-gpu-viv/imx-gpu-viv.mk#n55
> > >>
> > >> However I guess that would only fix the build but would cause issues
> > >> at runtime which might be confusing for users.
> > >
> > > It's not possible to ensure every possible configuration will be
> > > working. A simple example would be to compile a bootloader for a board A
> > > and a kernel for a completely different board B.
> > >
> > > Here, the configuration leading to this build error does not make sense.
> > > So if we only fix the build, leading to an unusable image I guess that
> > > would be OK. (And fixing the build is important, for build bots for
> > > example).
> >
> > I agree but here Thomas gave a green light on modifying the qtbase
> > package directly for this corner case which fixes both the build and
> > possible runtime issues.
>
> Reading Thomas' mail, I don't think he gave a green light on this.

Green light might be an overstatement indeed, but let's say he's not
against this kind of solution.

> So we still have to choose a solution to fix this (which may be the one
> directly modifying the qt5base package, but we first need to agree on
> the solution).

I agree, I think we have 2 viable solutions so far:
1) modifying the qt5base for this corner which fixes both the build
and runtime issues
2) modifying the eglvivante.h which is a more elegant solution but
only fixes the build, not the runtime issues.

I'm in favor of #1 because it's easy to implement, fixes both runtime
and build plus I personally don't have much time to test #2.

Regards,
Gary