[OE-core] [yocto] opengl / libgl / libgles

Koen Kooi koen at dominion.thruhere.net
Thu Sep 6 16:36:24 UTC 2012


Op 6 sep. 2012, om 18:10 heeft Tomas Frydrych <tf+lists.yocto at r-finger.com> het volgende geschreven:

> On 06/09/12 15:50, Koen Kooi wrote:
>> 
>> Op 6 sep. 2012, om 16:37 heeft Tomas Frydrych <tf+lists.yocto at r-finger.com> het volgende geschreven:
>> 
>>> On 06/09/12 14:51, Burton, Ross wrote:
>>>> On 6 September 2012 14:25, Koen Kooi <koen at dominion.thruhere.net> wrote:
>>>>> It's not automatic, but you can do something like this:
>>>>> 
>>>>>       http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=23b02134
>>>>> 
>>>>>       RDEPENDS_${PN} = "libGL"
>>>> 
>>>> Ah, interesting.  I'm not entirely keen on the manual dependencies but
>>>> that's certainly a step in the right direction.
>>> 
>>> Is there much that actually links against libGL / libgles? Things like
>>> cogl dlopen() these these, so you have to manually specify the RDEPENDS
>>> anyway. Just thinking this could be less of an issue than it might appear.
>> 
>> 
>> xbmc is one
> 
> The problem is basically the mesa package, right? If the mesa package is
> split so that the mesa libGL parts are provided separately from the more
> generic parts, and any GL bits, mesa or otherwise, are only built as a
> specific machine feature, then we will never have any GL bits in the
> non-machine part of the sysroot, and will always be dealing with the
> correct, and only, libGL. Packages that link directly to libGL would
> also be machine specific, but if we are talking about a hand full
> things, this is not a major issue. Or I am missing something?

No, that is pretty much exactly what I proposed earlier for mesa. 

> Ross, I think it gets unnecessarily complicated if you start thinking of
> it in the terms of hot-swapping libGL at runtime the way desktop distros do.

In theory it should work :)

regards,

Koen



More information about the Openembedded-core mailing list