On 12/20/2012 05:59 PM, Burton, Ross wrote: > On 20 December 2012 15:21, Phil Blundell <ph...@gnu.org> wrote: >> On Wed, 2012-12-19 at 18:03 +0200, Laurentiu Palcu wrote: >>> Since pango-native is built anyway and all the modules are in the native >>> sysroot, create the cache file by scanning those files instead of the >>> target files. The latter will fail because the shared objects wouldn't >>> be from the same ELF class. >> >> Is it guaranteed that the native build will have the same set of >> modules? It seems to me that it would be safer to scan the target ones >> under qemu as you did for gtk-immodules. > > I suspected there was no such real thing as an out-of-tree Pango > module, but I was wrong (http://graphite.sil.org/). But, in this case, we could use the qemu method only for the graphite package postinstall... We don't have to use it for pango too.
> > Digging quickly into the Debian packaging, they generate the modules > list at build time (not in a postinst) by running pango-querymodules > over the directories they just built, filtering the paths (this > happens in dh_pangomodules). They also generate a modules list file > per package and ship it, and pango reads the multiple files. I'm not > sure if this is upstream behaviour or a Debian-specific patch. How do they handle the cross-compiling issue? They cannot run the native pango-querymodules on a cross-compiled shared object. It will fail. Thanks, Laurentiu > > Ross > _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
