| Summary: | problems with gdk-pixbuf and pango loading on multilib | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jussi Kukkonen <jku> |
| Component: | core | Assignee: | Robert Yang <liezhi.yang> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | juro.bystricky, liezhi.yang, mark.hatle, meta.mr.watcher, meta.watcher, randy.macleod, ross.burton |
| Version: | unspecified | ||
| Target Milestone: | 2.3 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Jussi Kukkonen
2015-10-26 09:44:52 UTC
> 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.
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. 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. *** Bug 8580 has been marked as a duplicate of this bug. *** 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. (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. 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.
Yes, that last workaround is the best for now. Can you send a patch for the autobuilder? (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. I think I might not be the right assignee anymore? Is roberts python-smartpm work still relevant? Move it to 2.3 M2, we may not use smart any more in 2.3. Smart it gone. |