Op 6 sep. 2012, om 18:10 heeft Tomas Frydrych <[email protected]> het volgende geschreven:
> On 06/09/12 15:50, Koen Kooi wrote: >> >> Op 6 sep. 2012, om 16:37 heeft Tomas Frydrych <[email protected]> >> het volgende geschreven: >> >>> On 06/09/12 14:51, Burton, Ross wrote: >>>> On 6 September 2012 14:25, Koen Kooi <[email protected]> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
