FTBFS for XBMC on x86

[Avik Sil]

XBMC fails to build on x86:

CPP xbmc/cores/dvdplayer/DVDDemuxSPU.o
In file included from DVDDemuxSPU.h:24:0,
                 from DVDDemuxSPU.cpp:22:
DVDCodecs/Video/DVDVideoCodec.h:57:11: error: 'EGLImageKHR' does not name a type

This happens on 20111216 git snapshot. Seems the source need to include libegl1-mesa headers to have EGLImageKHR defined. Further investigation required as it was not happening on 20111206 git snapshot.

[Avik Sil (aviksil)]

Another FTBFS was there after merging Rob's gstreamer support patches:

CPP xbmc/cores/VideoRenderers/LinuxRendererGLES.o
In file included from
/home/linaro/xbmc/git/xbmc/xbmc/guilib/GraphicContext.h:47:0,
                 from LinuxRendererGLES.h:36,
                 from LinuxRendererGLES.cpp:30:
/home/linaro/xbmc/git/xbmc/xbmc/utils/StdString.h:1605:14: note: the
mangling of ‘va_list’ has changed in GCC 4.4
LinuxRendererGLES.cpp: In member function ‘void
CLinuxRendererGLES::CalculateTextureSourceRects(int, int)’:
LinuxRendererGLES.cpp:371:31: error: ‘GL_TEXTURE_EXTERNAL_OES’ was not
declared in this scope
LinuxRendererGLES.cpp: In member function ‘bool
CLinuxRendererGLES::CreateEGLIMAGETexture(int)’:
LinuxRendererGLES.cpp:1479:21: error: ‘GL_TEXTURE_EXTERNAL_OES’ was not
declared in this scope
make[1]: *** [LinuxRendererGLES.o] Error 1
make: *** [xbmc/cores/VideoRenderers/VideoRenderer.a] Error 2

It seems the /usr/include/GLES2/gl2ext.h header from libgles2-sgx-omap4-dev package defines GL_TEXTURE_EXTERNAL_OES, but that is specific to sgx driver. To make the XBMC working on all platforms, this define should be available in generic mesa header.

[Avik Sil (aviksil)]

Still getting the build error as in the bug description. Rob, can you please look into this? I've disabled gstreamer for i386. Should the EGLImage stuff be conditionally compiled with #if defined(HAVE_LIBGSTREAMER)?

[Rob Clark (rob-ti)]

it is orthogonal to gstreamer.. possibly we need to introduce an #if defined(HAVE_EGLIMAGE) ..

is it possible to just disable building on x86 for now? Ie. linaro doesn't really need to release x86 packages.

[Fathi Boudra (fboudra)]

On 4 January 2012 15:56, Rob Clark <email address hidden> wrote:
> it is orthogonal to gstreamer.. possibly we need to introduce an #if
> defined(HAVE_EGLIMAGE) ..
>
> is it possible to just disable building on x86 for now?  Ie. linaro
> doesn't really need to release x86 packages.

We have already done that as a workaround.

[Ricardo Salveti (rsalveti)]

On Wed, Jan 4, 2012 at 1:02 PM, Fathi Boudra <email address hidden> wrote:
> On 4 January 2012 15:56, Rob Clark <email address hidden> wrote:
>> it is orthogonal to gstreamer.. possibly we need to introduce an #if
>> defined(HAVE_EGLIMAGE) ..
>>
>> is it possible to just disable building on x86 for now?  Ie. linaro
>> doesn't really need to release x86 packages.
>
> We have already done that as a workaround.

We were interested at the fix for basically 2 reasons:
1 - The common packages are generated by the x86 build at Launchpad
(the workaround was to have it all for armel only);
2 - We want our patches to not break the normal use case, so later on
we can also propose the changes at Ubuntu;

So we'll keep armel-only for now, and first fix the issue with the
mesa-dev package. Later would be nice to have this fixed.

Cheers,
--
Ricardo Salveti de Araujo

[Rob Clark (rob-ti)]

yeah, makes sense.. probably need some help from someone else who isn't just hacking on this in spare weekend cycles like I am (and preferably who is a bit more familiar w/ xbmc) to get these patches into the shape where they can work on all archs and with all different combinations of xbmc build options. Right now all my spare cycles are going into just trying to make things like seeking work in a sane way ;-)

[Fathi Boudra (fboudra)]

digging into the issue, it appears that Rob's changes are a bit intrusive :) and relies on EGL being available on i386/amd64 build (which isn't the case as libegl1-mesa-dev isn't a build dependency).

A workaround is to build Rob's code conditionally using HAS_EGL.

I'm also a bit concerned by EGL_RAW_VIDEO_TI (or any TI/sgx specific extension) for upstreaming.

[Ricardo Salveti (rsalveti)]

On Tue, Jan 10, 2012 at 5:51 PM, Fathi Boudra <email address hidden> wrote:
> digging into the issue, it appears that Rob's changes are a bit
> intrusive :) and relies on EGL being available on i386/amd64 build
> (which isn't the case as libegl1-mesa-dev isn't a build dependency).
>
> A workaround is to build Rob's code conditionally using HAS_EGL.

That would probably be the way to go.

> I'm also a bit concerned by EGL_RAW_VIDEO_TI (or any TI/sgx specific
> extension) for upstreaming.

This is a problem also when enabling the same functionality at
qtmobility (for ubuntu tv), as these extensions are still proprietary,
and not generic enough.

Should this be something to be worked at the GWG?

[Fathi Boudra (fboudra)]

On 11 January 2012 00:46, Ricardo Salveti <email address hidden> wrote:
> On Tue, Jan 10, 2012 at 5:51 PM, Fathi Boudra <email address hidden> wrote:
>> digging into the issue, it appears that Rob's changes are a bit
>> intrusive :) and relies on EGL being available on i386/amd64 build
>> (which isn't the case as libegl1-mesa-dev isn't a build dependency).
>>
>> A workaround is to build Rob's code conditionally using HAS_EGL.
>
> That would probably be the way to go.

patch added, package uploaded in staging-overlay: xbmc
2:11.0~git20111216.68fff18-0linaro9

>> I'm also a bit concerned by EGL_RAW_VIDEO_TI (or any TI/sgx specific
>> extension) for upstreaming.
>
> This is a problem also when enabling the same functionality at
> qtmobility (for ubuntu tv), as these extensions are still proprietary,
> and not generic enough.
>
> Should this be something to be worked at the GWG?

we should certainly raise this concern. it's a blocker for upstreaming.

[Rob Clark (rob-ti)]

re: HAS_EGL around the rendering code, that sounds like the correct solution.

Only the part that is in gst decoder part, which creates the eglImage, is TI specific. And the extension is really just a stop-gap solution waiting for everything to work with dmabuf, and then GWG will implement a common dmabuf eglimg extension which could be implemented on multiple platforms.

[Ricardo Salveti (rsalveti)]

On Wed, Jan 11, 2012 at 11:13 AM, Fathi Boudra <email address hidden> wrote:
> On 11 January 2012 00:46, Ricardo Salveti <email address hidden> wrote:
>> On Tue, Jan 10, 2012 at 5:51 PM, Fathi Boudra <email address hidden> wrote:
>>> digging into the issue, it appears that Rob's changes are a bit
>>> intrusive :) and relies on EGL being available on i386/amd64 build
>>> (which isn't the case as libegl1-mesa-dev isn't a build dependency).
>>>
>>> A workaround is to build Rob's code conditionally using HAS_EGL.
>>
>> That would probably be the way to go.
>
> patch added, package uploaded in staging-overlay: xbmc
> 2:11.0~git20111216.68fff18-0linaro9

Great, thanks for the patch.

I saw that the package was built for armel already, but still waiting
for i386 and amd64. Did you build it at your x86 host and tested if it
would work fine?

Rob, maybe this is something you'd also like to integrate at your tree.

[Ricardo Salveti (rsalveti)]

On Wed, Jan 11, 2012 at 12:39 PM, Rob Clark <email address hidden> wrote:
> re: HAS_EGL around the rendering code, that sounds like the correct
> solution.
>
> Only the part that is in gst decoder part, which creates the eglImage,
> is TI specific.  And the extension is really just a stop-gap solution
> waiting for everything to work with dmabuf, and then GWG will implement
> a common dmabuf eglimg extension which could be implemented on multiple
> platforms.

Fair enough.

Don't know how easy would be to help pushing this support upstream,
but I believe besides working on a generic extension it should
probably need some rework ad the dvd player backend.

I didn't yet check the code in details, but guess if we at least have
it in a way it can detect the extension and use it at runtime, it can
at least be part of the packaging when pushing it to Ubuntu.

[Fathi Boudra (fboudra)]

On 12 January 2012 00:53, Ricardo Salveti <email address hidden> wrote:
> Great, thanks for the patch.
>
> I saw that the package was built for armel already, but still waiting
> for i386 and amd64. Did you build it at your x86 host and tested if it
> would work fine?

built and tested locally before uploading using 720p avi/mkv sample.
It works fine :)

> Rob, maybe this is something you'd also like to integrate at your tree.