k2 build failures

k2 build failures

[Stiffler, Jacob]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

With migrating to krogoth, the k2 build failures are due to conflicts between the ocl-gl-headers and mesa, and I've discovered why mesa is being pulled in.

In the opencv recipe, we are inheriting "cmake_qt5". This bbclass was changed to add the dependency on qtbase, and this brings in mesa for keystone.

I'm not sure of the best way to handle this. The easiest hack is the remove qtbase from the opencv dependencies for keystone only.

Would it be possible to replace opencl's dependency on "ocl-gl-headers" with "mesa-gl"? In the past, I made some attempts to use "mesa", but with the SGX platforms, there was always a conflict with the ti sgx drivers, as both were installing common gles files. I do not remember mesa-gl being an option before.

Thank you,
Jake

[-- Attachment #2: Type: text/html, Size: 2770 bytes --]

Re: k2 build failures

[Jacob Stiffler]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]



On 5/2/2016 2:59 PM, Stiffler, Jacob wrote:
>
> With migrating to krogoth, the k2 build failures are due to conflicts 
> between the ocl-gl-headers and mesa, and I’ve discovered why mesa is 
> being pulled in.
>
> In the opencv recipe, we are inheriting “cmake_qt5”. This bbclass was 
> changed to add the dependency on qtbase, and this brings in mesa for 
> keystone.
>
> I’m not sure of the best way to handle this. The easiest hack is the 
> remove qtbase from the opencv dependencies for keystone only.
>
> Would it be possible to replace opencl’s dependency on 
> “ocl-gl-headers” with “mesa-gl”? In the past, I made some attempts to 
> use “mesa”, but with the SGX platforms, there was always a conflict 
> with the ti sgx drivers, as both were installing common gles files. I 
> do not remember mesa-gl being an option before.
>

I treid replacing opencl's dependency on ocl-gl-headers with 
virtual/libgl. This appears to work for keystone, but for am57xx-evm, 
there is a conflict between mesa-gl and libgbm recipes as mesa-gl also 
provides a libgbm package. How can this conflict be resolved?

> Thank you,
>
> Jake
>
>
>
> _______________________________________________
> meta-arago mailing list
> meta-arago@arago-project.org
> http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago


[-- Attachment #2: Type: text/html, Size: 4027 bytes --]

Re: k2 build failures

[Denys Dmytriyenko]

On Tue, May 03, 2016 at 08:25:27AM -0400, Jacob Stiffler wrote:
> 
> 
> On 5/2/2016 2:59 PM, Stiffler, Jacob wrote:
> >
> >With migrating to krogoth, the k2 build failures are due to
> >conflicts between the ocl-gl-headers and mesa, and I’ve discovered
> >why mesa is being pulled in.
> >
> >In the opencv recipe, we are inheriting “cmake_qt5”. This bbclass
> >was changed to add the dependency on qtbase, and this brings in
> >mesa for keystone.
> >
> >I’m not sure of the best way to handle this. The easiest hack is
> >the remove qtbase from the opencv dependencies for keystone only.
> >
> >Would it be possible to replace opencl’s dependency on
> >“ocl-gl-headers” with “mesa-gl”? In the past, I made some attempts
> >to use “mesa”, but with the SGX platforms, there was always a
> >conflict with the ti sgx drivers, as both were installing common
> >gles files. I do not remember mesa-gl being an option before.
> >
> 
> I treid replacing opencl's dependency on ocl-gl-headers with
> virtual/libgl. This appears to work for keystone, but for
> am57xx-evm, there is a conflict between mesa-gl and libgbm recipes
> as mesa-gl also provides a libgbm package. How can this conflict be
> resolved?

Lately I've been pushing for changes in that area in upstream, so there's some 
understanding and agreement, but there are several levels of change required 
and some details are still being worked on... Hopefully I can convince the 
upstream graphics guy to push the initial mesa-gl/libgbm decoupling patches 
in, which I already tested, but he's on vacation now after the release last 
week. So, it will take some time to do it properly, even though it's been 
progressing slowly for a while. Meanwhile we can make it work by patching 
cmake class, if needed...

-- 
Denys