8570 2015-10-26 09:44:52 +0000 problems with gdk-pixbuf and pango loading on multilib 2017-03-16 06:26:44 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED INVALID Medium+ normal 2.3 M3 1 jku liezhi.yang juro.bystricky liezhi.yang mark.hatle meta.mr.watcher meta.watcher randy.macleod ross.burton --- --- No (bug/feature does not impact docs) oldest_to_newest 55721 0 jku 2015-10-26 09:44:52 +0000 Can't say I fully understand this yet but filing a bug as one doesn't seem to exist yet. Richard wrote an explanation in email: > With the recent fixes to gdk-pixbuf loaders, we're now seeing a 100% > reproducible problem with the second multilib test on the autobuilder. > The reproducer is: > > require conf/multilib.conf > MULTILIBS = "multilib:lib32" > DEFAULTTUNE_virtclass-multilib-lib32 = "x86" > RPM_PREFER_ELF_ARCH = "1" > IMAGE_INSTALL_append = " lib32-connman-gnome" > MACHINE = "qemux86-64" > > bitbake core-image-sato > > then watch as you see errors trying to run connman-applet due to no > pixbuf loaders. > > The problem is that it installs lib32-gdk-pixbuf and lib32-libgtk+ > however it doesn't install any lib32 gdk-pixbuf loaders. > > Since lib32-libgtk+ RRECOMMENDS several, it probably should, however > this is crazy rpm mutilib so it assumes the non lib32 variant can > actually handle its needs when it clearly can't. ... > FWIW, I did try: > > IMAGE_INSTALL_append = " lib32-connman-gnome lib32-gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-jpeg" > > however whilst this fixed the connman-applet start errors, the icons on > the desktop disappeared, I worry that the icon cache format is multilib > specific and you can't run two different sized libgtk on the same icon > directory. So there might be two problems here: 1. We need to be able to describe the dependencies correctly -- Robert, you had a possible fix for this, correct? 2. We may need separate loader caches for different lib-versions. 55735 1 jku 2015-10-26 12:37:22 +0000 > 2. We may need separate loader caches for different lib-versions. Actually, this seems to work just fine: if I make sure the pixbuf loaders are installed for both lib versions, sato desktop finds the 64 bit ones and the connman applet finds the 32 bit ones. There is a follow-up bug though: the applet mis-renders all text and says Pango-CRITICAL **: no modules found. No builtin or dynamically loaded module were found. PangoFc will not work correctly It seems Pango has the same problem: the 32 bit modules are not installed. 55743 2 mark.hatle 2015-10-26 14:12:24 +0000 Lets take a step back here. Why are we installing the 32-bit connman and not using the 64-bit? Is this an issue where we are building a very large multilib system for testing purposes, or is this a real world situation like glibc-std-sato or something? I don't believe we have seen this problem very often because multilib is usually used for select implementations of components a user wants to make available for the alternative library format vs building everything for the multilib. (That is not to say there isn't a bug here, I'm sure there is...) I'm just worried we've moved to an artificial test case that is not likely to affect someone in a more real-world situation. 55751 3 ross.burton 2015-10-26 14:55:10 +0000 It's for sanity testing: can we build a 64-bit image with a select component being 32-bit. The complication that said component (connman-gnome) uses GTK+, gdk-pixbuf, and Pango, all of which have runtime loadable modules, sure is making this more of a test than you'd expect but it isn't unusual in my opinion. 55893 4 jku 2015-10-28 11:22:06 +0000 *** Bug 8580 has been marked as a duplicate of this bug. *** 55903 5 jku 2015-10-28 12:38:30 +0000 For those following at home, Roberts python-smartpm patch and related discussion: http://lists.openembedded.org/pipermail/openembedded-core/2015-October/112050.html (In reply to comment #2) > Lets take a step back here. Why are we installing the 32-bit connman and > not using the 64-bit? Is this an issue where we are building a very large > multilib system for testing purposes, or is this a real world situation like > glibc-std-sato or something? I think the choice here is not unreasonable: connman-applet is a pretty basic GUI application (it shouldn't actually install 32bit connman itself since the API is D-Bus). That said, maybe this is too ambitious for 2.0? We could change the test case to something that does not use dynamically loaded modules (in other words, not a GTK+ application), and if multilib is in the releases notes mention that the support does not cover that case yet. 55962 6 jku 2015-10-29 08:53:03 +0000 (In reply to comment #5) > That said, maybe this is too ambitious for 2.0? We could change the test > case to something that does not use dynamically loaded modules (in other > words, not a GTK+ application), and if multilib is in the releases notes > mention that the support does not cover that case yet. As a concrete suggestion: IMAGE_INSTALL_append = " lib32-connman-client" This is the command line connman client instead of the GUI client. It results in installing these 32 bit packages and seems to work fine: lib32-connman-client x86 1.30 lib32-glibc-locale-en-gb x86 2.22 lib32-libc6 x86 2.22 lib32-libdbus-1-3 x86 1.8.20 lib32-libffi6 x86 3.2.1 lib32-libglib-2.0-0 x86 2.44.1 lib32-libglib-2.0-locale-en-gb x86 2.44.1 lib32-libreadline6 x86 6.3 lib32-libtinfo5 x86 5.9 lib32-libz1 x86 1.2.8 I haven't really looked if this brings any value on top of the other multilib tests as it is. 56045 7 jku 2015-10-30 13:18:44 +0000 Oh, one more workaround option for 2.0.x: Add both 32 and 64 bit versions of module packages to IMAGE_INSTALL_append by hand: lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc This makes connman-applet work fine as a 32 bit app. 56078 8 ross.burton 2015-11-02 11:00:16 +0000 Yes, that last workaround is the best for now. Can you send a patch for the autobuilder? 56084 9 jku 2015-11-02 11:56:32 +0000 (In reply to comment #8) > Yes, that last workaround is the best for now. Can you send a patch for the > autobuilder? Done, bug 8624 is for the workaround. 56578 10 jku 2015-11-18 13:07:22 +0000 I think I might not be the right assignee anymore? Is roberts python-smartpm work still relevant? 67197 11 liezhi.yang 2016-10-13 07:01:48 +0000 Move it to 2.3 M2, we may not use smart any more in 2.3. 71340 12 liezhi.yang 2017-03-16 06:26:44 +0000 Smart it gone.